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

看看大多数智能体框架提供的循环原语：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 设计，它定义了两类调用者，将它们的流量视为不同的形态，并记录委托链，以便在间接层级中保持可追溯性。

用户点击了智能体操作的“撤销”按钮，而该操作之前已经分发（fan out）到了十二个工具调用中。智能体发送了两封电子邮件，创建了一个日历邀请，更新了一条 CRM 记录，扣除了信用卡费用，并在 Slack 频道中发布了消息。其中三个操作通过 API 是不可逆的。两个操作只能通过触发自身下游通知的反向操作来撤销。剩下的七个操作各自都有自己的幂等性（idempotency）定义，而规划器从未协调过这些定义。你发布的撤销按钮看起来令人安心，它大约 60 % 的时间静默成功，其余时间则静默失败。

这不是一个 UX（用户体验）漏洞。这是一个 Saga 模式问题，分布式系统工程师已经研究了三十年，而忽略这段历史是发现它最昂贵的方式。

无状态的聊天补全（Stateless chat completion）耗电量极低。一次中等规模的 Gemini 文本提示耗电约为 0.24 Wh；一次简短的 GPT-4o 查询约为 0.3–0.4 Wh。这些数字微乎其微，甚至没人会把它们放进董事会演示文稿里。

智能体任务（Agent task）并非普通的聊天补全。一个典型的“研究该客户并起草回复”的工作流可以扇出（Fan out）到 30 多个工具调用、10–15 次模型调用，且上下文窗口随着每一步不断增长。能源成本随调用图（Call graph）呈复合增长。当智能体返回结果时，你消耗的不是一个推理单元，而是五十到两百个。突然之间，每个任务的碳足迹便与视频流达到了同一数量级。

这种算术题很快就会在工程部门之外产生影响。欧盟的 CSRD 使范围 3（Scope 3）排放披露成为受规制公司的强制要求，并要求从 2026 年起提交机器可读的 iXBRL 报告。尽管 SEC 在其最终规则中删除了范围 3，但任何在欧盟有业务的跨国公司仍然必须回答这个问题。采购团队已经开始在供应商调查问卷中加入“你的 AI 功能每个用户任务的碳足迹是多少？”这类问题。大多数工程团队无法回答，因为从来没有人测量（Instrumented）过它。

当 CFO 第一次问“这个助手每月花掉我们多少钱”时，工程团队会给出一个数字。第二次问时，另一个团队会给出不同的数字。第三次问时，财务部门会给出第三个数字，然后有人会打开一个电子表格，尝试从 Span（跨度）中重新推算账单，因为没有人再相信之前的任何答案。就在这一刻，复合 AI 系统（Compound AI System）不再仅仅是一个架构问题，而变成了一个会计问题。

这种故障的形式是结构性的。一个简单的用户请求“总结我上季度的客户反馈”会触发由团队 A 拥有的智能体，它调用由团队 B 维护的检索工具，接着调用由供应商 X 托管的模型，然后通过团队 C 的重排序工具回传结果，而重排序工具又调用了由供应商 Y 提供的另一个模型。一次点击；五个所有者；两张相隔一个月到达的账单。标准的 FinOps 原语——成本中心、分配标签、账号级汇总——是为了切割那些已经拥有稳定所有者的基础设施而设计的。它们无法清晰地组合在一个每次请求都会跨越团队边界的内部调用图中。

《2026 年 FinOps 现状报告》指出，98% 的 FinOps 团队需要对 AI 支出负责，而同一份调查将“对 AI 成本的实时可见性”列为最大的工具缺口。这个缺口并不是“我们看不见账单”，而是“我们无法足够快地看清是账单的哪一部分是由谁产生的，以至于无法在账单寄到之前让任何人改变其行为”。