161 篇博文 含有标签「agents」

你见过的每一个 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 毫秒究竟消耗在了哪里。

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

这种场景每次都如出一辙。你的智能体正在预订酒店房间，支付API调用返回200后、确认信息存储之前发生了网络超时。智能体框架发起重试，支付再次执行，客户被扣了两次款。支持团队升级处理，某位高管说AI"幻觉出了重复扣款"——这种说法是错的，但听起来有道理，因为没人愿意承认他们的重试逻辑从一开始就是坏的。

这不是AI问题，而是分布式系统问题——被AI层全盘照搬，却没有带来分布式系统工程师几十年苦心钻研出的应对之道。标准的智能体重试逻辑假设操作是幂等的，而大多数工具调用并非如此。

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。

Writer 团队在对其 RAG-MCP 基准进行插桩测试时发现，当 Agent 可以访问大量工具集时，基准工具选择准确率——在无任何特殊处理的情况下——仅为 13.62%。不是 80%，不是 60%，而是 13%。而同一个 Agent，在通过检索增强的工具选择仅暴露最相关子集后，准确率达到了 43%。工具没变，模型没变，唯一变化的是推理时可见的工具定义数量。

这就是工具过载问题，它正在悄无声息地摧毁大规模生产 AI 系统。

在一百万份干净文档中隐藏五份精心构造的恶意文档，就能对生产级RAG系统实现90%的攻击成功率。这不依赖零日漏洞或密码学破解——只需用纯文本指示模型以与运营者意图不同的方式运行。如果你的防御策略是"在内容到达LLM之前净化输入"，那你已经输了。

框架至关重要。将提示注入视为输入验证问题的团队会构建边界防御：正则过滤器、基于LLM的分类器、输出扫描器。这些有用但不足。真正的问题在于，现代AI系统是组件的组合——检索器、知识库、工具执行器、外部API——每个组件都是有自身攻击面的摄入点。这正是供应链漏洞的定义。

大多数团队在发布第一个可执行代码的智能体（Agent）时，只采取了一种安全控制措施：API 密钥范围限制（API key scoping）。他们给智能体一个具有 repo:read 权限的 GitHub 令牌，以及一个可以访问工作目录的 shell，然后就称其为“已沙箱化”。这种做法是错误的，其弊端只有在发生安全事故后才会变得显而易见。

能够编写和执行代码的智能体的威胁模型与 Web 服务器或 CLI 工具的威胁模型有着本质的区别。攻击面不再是协议边界，而是智能体读取的一切内容。这包括 git 提交记录、文档页面、API 响应、数据库记录以及它打开的任何文件。其中的任何输入都可能包含提示词注入（prompt injection），从而将你的研究型智能体转变为数据泄露管道。

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。