LLM代理

不同数据源的schema差异巨大（日期格式、货币单位、缺失值表示、嵌套层级各不相同），代理拿到原始JSON后往往需要额外的LLM步骤做字段映射，这既增加token成本又引入不确定性。

LLM代理是位于应用和LLM提供商之间的中间层，记录请求和响应以监控延迟、成本、错误和模型行为。

在LLM代理场景中，最小权限必须细化为“逐调用最小权限”，因为若权限边界绑定到会话而非单次调用，会随链条延长而不断被放大。

作者的LLM代理运行在localhost，暴露OpenAI和Anthropic兼容端点，使用Aho-Corasick字符串匹配进行关键词路由，微秒级开销，与知识图谱使用同一个crate。

作者强调节省的模式是按会话或按场景路由，而不是每轮随机切换模型；应为任务选定一条通道并留在上面。

在共享对话记忆条件下，LLM代理在22%的合格决策中偏离了当前客户的目标，被之前交互中残留的目标表征所干扰。

持久化LLM代理缺乏关系特定的状态隔离，KV缓存中的目标表征会跨越关系边界泄露并影响后续决策。

共享记忆虽然提升了上下文连贯性，却可能以牺牲决策忠实度为代价。

为每个客户关系维护独立的缓存分区、在切换客户时主动清理或屏蔽无关的目标表征、或设计动态标记目标归属的注意力机制，是应对目标泄露的潜在工程方向。

设计多客户代理系统时，状态隔离不应被视为可选的优化项，而是确保行为忠实度的基础要求。