191 篇博文 含有标签「agents」

工具描述不是文档。它是模型在每一轮对话中都会读取的 prompt，用于决定该工具是否触发以及如何触发。你不是在为对接该工具的开发者编写内容——开发者已经在 PR 中看到了 schema、类型和示例。你是在为一个从未见过这个代码库的随机读者编写内容，它在同一个上下文窗口中还拿着另外二十个工具描述，并且必须在下一次前向传播中选出一个。

大多数团队并没有意识到这一点。他们把 OpenAPI 摘要粘贴到 description 字段中，把 JSON Schema 贴在下面，然后就发布了。结果，agent 调用工具的次数过少，或者自信地调用了错误的邻近工具，又或者用了任何读过 schema 的人类都会觉得“显而易见”是错误的参数来调用正确的工具。团队责备模型，但模型读取的正是一字不差的你写的内容。

你在一个工具 schema 中将 query 重命名为 search_query。变更日志写着：“非破坏性更名：更清晰的命名”。PR 通过了评审。三天后，你的支持队列里塞满了关于助手“搜索结果为空”的报告。发生的事情并不是讨论帖里任何人会告诉你的。智能体（Agent）并没有失败。它们提交了旧的字段名称，你的工具服务器忽略了未知的 key，将 search_query 默认设置为空字符串，并返回了零条结果。模型看到一个看起来很正常的空响应，便自信地向用户解释为什么他们的查询没有返回任何相关内容。

这是智能体工程（Agent Engineering）中不符合从 REST API 版本管理借鉴来的心理模型的部分。发送已重命名字段的 REST 客户端会收到 400 错误和清晰的报错——该字段要么存在于验证器中，要么不存在。而发送已重命名字段的智能体得到的则是静默接受、一个毫无意义的结果以及一段幻觉式的合理解释。失败不在于线路传输（the wire）；而在于运行时 schema 与模型关于工具外观的上下文心理模型（in-context mental model）之间的脱节。

工具 schema 存在于两个地方。第一个是运行时规范（runtime spec）——即你发布到 MCP 服务器或函数调用注册表的 JSON schema。第二个是该规范在模型中的上下文表示，它通过系统提示词（system prompt）中的 few-shot 示例、智能体在多轮任务中看到的序列化工具历史记录，以及模型在预训练期间已经吸收的关于你 API 的知识来在每一轮对话中不断强化。你可以原子化地更新前者，但你无法原子化地更新后者。这种不对称性就是问题的核心，这也是为什么“仅限添加，永久保留”——protobuf 和 GraphQL 运营商在十年前就已经内化的原则——现在需要迁移到工具 schema 层了。

一个在所有转写层级基准测试（benchmark）中得分完美的语音智能体，在实际通话中可能仍然让人感觉有些微妙的不对劲。文字没错，推理也没错。仪表盘上的端到端延迟显示为 520ms，这正是预期的目标。然而，电话另一端的人却不断卡顿、抢话、重说，甚至提前挂断。团队发布了更好的模型，数据提升了，但体感依然没有改善。

究其原因，与模型说了什么几乎无关，而与它何时说话几乎全盘相关。语音并非仅仅是附带了音频的文本。人类的对话运行在一个严密的半双工（half-duplex）协议之上，包含插话（barge-in）、反馈信号（backchannel）和重叠语音，其时间预算是以毫秒计算的。大多数语音智能体的问题，在解决了第一周的幻觉修复后，本质上都是轮次协商（turn-negotiation）问题。而轮次协商是架构层面的问题——你无法通过提示词工程（prompting）来解决它。

大多数工程师在构建第一个 LLM agent 时，都会遵循相同的流程：写一个系统提示词，添加一个调用模型的循环，撒上一些工具调用逻辑，然后看着它在简单的测试用例上运行。六周后，这个 agent 变成了一团难以理解的嵌套条件、粘贴在 f-string 里的 prompt 片段，以及散落在三个文件中的重试逻辑。添加一个功能需要通读整个代码。遇到生产 bug 就得盯着一个上千 token 的上下文窗口，试图重建模型当时在"想"什么。

这就是"意大利面式 agent"问题，在以 prompt 为起点而非设计为起点的团队中几乎普遍存在。解决方案不是更好的提示技巧，也不是换一个框架，而是一种纪律：在写第一个 prompt 之前，先设计好状态机。

每个部署过分布式系统的工程师都曾直面CAP定理并做出抉择：当网络分区时，你是继续提供陈旧数据（可用性），还是拒绝服务直到获得一致的答案（一致性）？该定理告诉你，二者不可兼得。

AI智能体面临着同样的权衡，然而几乎没有人在明确地做出这一选择。当你的LLM调用超时、工具返回垃圾数据、下游API不可用时——你的智能体会怎么做？在大多数生产系统中，答案是：它会猜测。悄无声息地。信心满满地。而且往往是错的。

故障模式并不戏剧化。日志中没有异常。智能体"回答"了用户。两周后才有人问起，为什么系统订了错误的航班、提取了错误的实体，或者自信地告诉客户一个已不存在的价格。

你的 Agent 在隔离测试中表现完美。你对每个步骤都做了基准测试，测量得到每步精确率为 95%。向利益相关者演示时效果很好。然后你上线了，用户反映几乎有一半时间它都会失败。

这个失败不是任何单个组件的 bug，而是数学。

你见过的每一个 Agent 演示都以干净的结果收尾。工具调用返回了模型预期的数据，响应在两秒内到达，最终答案清晰准确。那是演示。生产环境则是另一回事。

在生产环境中，工具会超时。API 会返回 403，因为某个服务账户上周二被轮换了。第三方数据丰富端点返回 200，但响应体写着 {"status": "degraded", "data": null}。OAuth 令牌在周六凌晨 3 点过期。这些不是边缘案例——这是任何与真实世界交互的 Agent 的正常运行状态。失败模式是可预见的。问题在于，大多数 Agent 架构将它们视为事后补救，而大多数 Agent UI 根本没有向用户传达这些失败的词汇。

每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。

问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。

一个团队交付了一个文档处理智能体（agent）。它在开发环境中表现完美：读取文件、提取数据、将结果写入数据库，并发送确认 webhook。他们运行了 50 个测试用例，全部通过。

部署两周后，在 100 个并发智能体实例运行时，数据库中出现了 40,000 条重复记录，三个下游服务收到了数千个虚假的 webhook，一个共享配置文件被两个同时运行的智能体各覆盖了一半。

智能体本身没有出错。系统崩溃是因为没有任何一个独立的智能体测试曾被要求与其他智能体共同处于同一个运行环境中。

你写了一份详尽的规范。你描述了任务，列出了约束条件，并给出了示例。Agent 运行了——但做了一些与你预期完全不同的事情。

这就是规范差距 (specification gap)：你写的指令与 Agent 理解的任务之间的距离。这不是模型能力的问题，而是规范的问题。2025 年发布的关于多 Agent 系统失败的研究发现，与规范相关的议题占所有失败的 41.77%，而 79% 的生产环境故障可以追溯到任务是如何规范化的，而不是模型能做什么。

大多数编写 Agent 规范的团队都在犯同一类错误：像给一个称职的同事写邮件一样写指令，然后期望一个没有任何共享上下文的自主系统在数千次运行中正确执行这些指令。

每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。

对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。

大多数分布式追踪方案在引入 Agent 之前都运作良好。一旦系统中出现 Agent A 跨微服务边界调用 Agent B——Agent B 调用工具服务器、工具服务器再查询向量数据库——原本连贯的端到端视图就会碎片化为互不相连的片段。追踪后端展示的是一个个孤立的操作，而你失去的是因果链：为什么某件事发生了，哪个用户请求触发了它，以及那 800 毫秒究竟消耗在了哪里。

这不是监控配置问题，而是上下文传播架构问题。它有着特定的技术形态，大多数团队都是在付出代价后才意识到这一点。