311 篇博文 含有标签「ai-agents」

当产品团队第一次需要针对每个用户的智能体（agent）行为时，通常会有人说“我们应该进行微调”或“让我们接入持久化内存”。一周后，他们拥有了向量数据库、反馈循环流水线，以及监控学习状态漂移的路线图项。他们构建了一个机器学习系统来解决一个在十有八九的情况下其实只是配置文件的问题。

看看用户真正想要的是什么：更简洁的回答、要点列表而非散文、免责声明中包含我的公司名称、默认使用我偏好的模型、100 美元以下不要转接到人工、这是我本周正在处理的项目、永远不要使用表情符号。这些都不需要模型去学习任何东西。它需要的是设置（settings）。Dotfile 模式——一个版本化的、声明式的、针对每个用户的配置库——在四十年前就为 shell、编辑器和 CLI 解决了这个问题，而这正是 2026 年 AI 智能体的正确形态。

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。

这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。

看看大多数智能体框架提供的循环原语：continue、return、retry 以及一个硬性终止运行的步数预算。注意缺失了什么。这里有一条表示“工作成功”的路径，一条表示“模型想继续”的路径，还有一条表示“我们耗尽了资金或耐心，于是强行终止循环”的路径。唯独没有一条头等路径来表达“我正在执行的计划是错误的，我想将其丢弃并开始一个全新的计划”。放弃原语（abandon primitive）——即一种让规划器显式、结构化地宣布当前轨迹无望的方式——是智能体循环语法中缺失的动词。它的缺失导致了一类通常被误诊为“模型需要更多推理”的失败。

一个在注定失败的分支上执行了三步的规划器，会不断优化同一个错误的计划，因为循环唯一的出口是成功、重试上一步或耗尽预算。这些路径都不包含“放弃该策略并尝试另一个”。因此，智能体执行了循环所允许的操作：它就地修改计划、再调用一个工具、再请求一次澄清，并在步数预算耗尽前不断收敛到一个非解决方案。当最终撞墙时，用户看到的是一条礼貌的失败消息，而不是问题的答案。这些浪费的步骤所带来的成本是真实的——生产数据表明，智能体系统 5-10% 的 Token 支出都花在了无法产生任何可用结果的重试上，而这一数字主要由长期的“注定失败分支”占据，而非孤立的工具错误。

当财务团队第一次要求 AI 产品团队预测单位经济效益（unit economics）时，对话往往如出一辙。团队打开推理仪表盘，指着每月的 token 支出说：“这就是我们的销售成本（COGS）。”CFO 乘以预估业务量，在图表上画出一条线，并询问毛利率曲线何时能跨过 70%。六周后，当实际损益表（P&L）出炉时，仪表盘上的推理数字是正确的，但毛利率却比预测低了 20 个百分点。没人撒谎。推理费用其实只占 Agent 实际成本的一半。

另一半成本分散在 AI 团队中无人负责的各个分项中。向量数据库的账单在悄无声息地增长，因为检索量随使用量增加，而重新索引的成本计入了计算费用，而非存储费用。可观测性平台的发票则从平台团队的预算中支出。嵌入重构（Embedding regeneration）表现为 CI 成本。遥测数据存储被归入数据仓库。人工审核则计入客户成功（customer-success）的人员成本。这些项目单独看都不起眼 —— 这正是为什么整合后的数字会让所有人大吃一惊。

如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。

这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。

安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。

这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。

每个智能体产品的安全仪表盘上都应该有一个数字，但几乎没人追踪它：随时间推移的人均批准率。发布一个“我可以发送这封邮件吗”或“我可以针对生产环境运行此查询吗”的权限提示，其曲线每次都如出一辙。第一天，用户会犹豫、阅读，有时会点击“不”。到了第二周，这已经是本小时内的第五次提示，拒绝的代价是必须由你亲自完成工作，于是点击率会收敛到 95% 以上。团队的安全叙事仍然声称用户批准了每一项操作。但在任何实质性的认知层面上，用户并没有。

这不是一个可以通过更好的文案来修复的 UX 问题。这是使 Cookie 横幅、浏览器 SSL 警告和 Windows UAC 对话框失效的同一种习惯化现象，只是应用在了一个运行速度比以往快几个数量级的底座上。许可门槛是一种具有半衰期的安全控制。如果在发布时不衡量它的衰减速度，你发布的只是一个用户到第二周就会习惯性忽略的复选框 —— 以及一个依赖于不再具有任何意义的点击的合规叙事。

你的审核员今天早上做出的第 50 个决策与第 1 个决策的质量并不相同。架构图不会显示这一点。容量模型不会显示这一点。跟踪“每小时审批量”的仪表盘甚至在主动掩盖这一点。然而，你的人机回环（Human-in-the-loop，简称 HITL）系统的整个前提——即由人来捕捉模型产生的错误——从队列开始填充的那一刻起就在无形中退化。

大多数 HITL 设计将审核员的时间视为一种无限的、可互换的资源。团队设置一个置信度阈值，将所有低于该阈值的项路由到人工队列，并宣布系统是“安全”的。六周后，审批率已悄然升至 96%，队列深度是人员配置模型假设的两倍，抽样审计显示审核员正在对他们在第一天会标记出来的边缘案例点击“批准”。系统并没有崩溃，它只是通过“橡皮图章”式的盲目审批，让自己看起来运转良好。

在你的技术栈中，每一个设计良好的 HTTP API 都会返回分页结果。没有人会把一百万行数据加载进内存并祈祷一切顺利。然而，你的智能体（agent）所调用的工具却会返回整个列表，而智能体也会尽职尽责地阅读它，因为函数签名写的是 list_orders() -> Order[]，且智能体不像人类用户那样拥有“滚动并加载更多”的协议。

智能体在原本可以跳过的行上浪费了 Token。拥有 50K 记录的长尾客户遇到了中等规模客户从未见过的上下文窗口失败。工具作者无法从追踪（trace）中判断智能体是需要所有这些行，还是仅仅因为无法请求更少的数据。而且，在你评估套件的某个地方，原本会标记这种退化的回归测试从未运行，因为每个测试固件（test fixture）的记录都少于 100 条。

分页不是一种 UI 交互功能。它是一种负载卸载（load-shedding）原语 —— 而在没有分页的情况下使用工具的智能体，正在重新犯下你们公司的 API 设计师们花了十年时间才学会避免的每一个 SELECT * FROM orders 错误。

你长期运行的智能体（agent）所做的最危险的事情，也是它做得最自信的事情：根据记忆回答。客户的地址在上周二更改了。智能体认为“开启”的工单在昨天被人工关闭了。智能体拥有整洁解释笔记的产品功能，其实际交付的形式与智能体三周前阅读的规范不同。在教科书定义上，这些都不属于幻觉——模型准确地召回了它存储的内容。只是在智能体看向别处时，世界已经发生了变化。

大多数团队将记忆视为一个写入问题：智能体应该记住什么、我们如何总结、嵌入（embedding）策略是什么、如何防止存储爆炸。这种思维方式产生的架构会随着错误程度的增加而变得更加自信。更难的问题——那个决定你的智能体在第三周后是否仍然有用的问题——是对账（reconciliation）：这是一个明确的、持续的闭环，用于比较智能体认为真实的情况与底层系统当前显示的真实情况。

你两年前发布的 API 是为单一类别的调用者设计的：浏览器或移动客户端背后的人，点击一次，然后等待响应。现在，大约一半的关键端点上，这个假设都是错误的。另一半流量是智能体（Agents）——你自己的、你客户的，或者是将你的端点作为工具使用的第三方集成——它们具有不同的运行逻辑。它们会产生爆发式流量。它们会无限重试。它们会并行处理。它们会逐字解析错误字符串。它们代表人类行事，而当出现问题时，人类无法即时提供意图说明。

今年出现在复盘报告（postmortems）中的大多数生产环境异常，都可以追溯到一个架构错误：将这两类调用者视为同一种类别。为人类步调设置的频率限制（Rate limits）会被智能体的并行扇出瞬间击穿。为人类可读而设计的错误消息，会被一个在 400 错误上无限重试的智能体解析错误。人类默认会满足的幂等性假设，在智能体从恢复的检查点重试相同的负载时会被打破。身份验证日志失去了区分“用户执行了此操作”与“用户的智能体代表用户执行了此操作”的能力。

解决方法不是更智能的 WAF 或更大的频率限制桶。而是一种深思熟虑的 API 设计，它定义了两类调用者，将它们的流量视为不同的形态，并记录委托链，以便在间接层级中保持可追溯性。