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

你的下一次定级会（calibration meeting）存在一个没人愿意点破的衡量问题。委员会面前的材料显示，一名工程师在这半年提交了 340 个 PR，而另一名只提交了 90 个。五年前，这种差距意味着某些实质性的东西。而今天，它主要告诉你的是谁拥有更好的 Agent 工具链，谁的团队拥有更宽松的审查文化，以及谁对合并生成代码的容忍度更高。幻灯片上的数字衡量的是机群（fleet）。而委员会本应评估的是人。

这并非某种未来才会发生的虚构趋势。行业分析估计，在认真采用 Agent 的公司中，AI 编写的代码已占提交代码的 30% 左右；一项针对 300 名工程师的纵向研究发现，在采用 Agent 后，团队生成的 Pull Request 数量增加了 98%。你的评审流程从“前 Agent 时代”继承下来的每一项产出指标——代码行数变化、合并的 PR 数量、Story points、速率（velocity）——现在都是人类判断力和机器吞吐量的混合衡量，两者之间没有明确的归因界限。定级委员会正在比较这些混合数字，就好像他们仍在衡量人一样。

询问任何基础设施团队，要求将生产数据库恢复到昨天下午 3 点的状态，他们会向你提供一份操作手册 (Runbook)、一个 RPO 以及一份预估时间。但如果询问同一个团队，要求将 Agent 恢复到昨天下午 3 点的状态——在它吸收一批中毒的记忆之前，在有人发布错误的提示词版本之前，或者在那个悄无声息地破坏了检索的重新索引之前——你得到的将是沉默。这并不是因为各个组件缺乏备份，而是因为没有人能说出“下午 3 点的 Agent”究竟意味着什么。

这是每个运行学习型 Agent 的团队都会面临的尴尬发现：你的数据库有快照，你的代码有 git，而你的 Agent——那个用户真正与之交互的东西——两者都没有。它的运行状态散落在向量索引、一堆记忆文件、提示词注册表和一套工具配置中，这些组件要么各自拥有独立的版本，要么根本没有版本。仅恢复其中任何一个都无法找回昨天的 Agent。你得到的只是一个逻辑破碎的大脑。

这是一个在每一个发布 Agent 的团队中都会重复发生的迁移故事。你基于某个供应商的 SDK 构建了你的 Agent。工具定义以该供应商预期的 JSON Schema 形式存在。工具结果被格式化为该供应商的消息结构。接着，某些原因迫使你做出改变 —— 竞争对手发布了更好的模型，采购部门为了冗余要求引入第二个供应商，或者一个 MCP 服务器取代了手写的集成 —— 然后你发现迁移的真正工作量：它不仅仅是一个 API 客户端。它是代码库中的每一个工具定义、每一个结果格式化器、每一个重试处理器以及每一个测试固件。

失败的原因并不是你选错了供应商。而是你让别人的序列化格式变成了你的内部架构。针对这个问题，早在二十年前就有了一个答案 —— Alistair Cockburn 的六边形架构，更广为人知的名字是“端口与适配器” —— 而 Agent 系统是它多年来最引人注目的新用例。

1980 年，Jon Postel 在 TCP 规范中写下了一句话，这成为了互联网的奠基原则：“对自己发送的内容要保守，对接收的内容要宽容。”四十年来，工程师们将其应用到各个角落——容忍尾随逗号的解析器、将 "10" 强制转换为 10 的 API、静默修复错误标记的 HTML 渲染器。可以说，万维网之所以存在，是因为浏览器宽容了所有人的错误。

然而，当调用者不再是人类时，这条建议就反转了。当一个 AI Agent 调用你的工具并传入字符串类型的数字、嵌套错误的 JSON 对象，或者一个 几乎 正确的枚举值时，那个原本能节省人类开发人员 20 分钟调试时间的宽容解析器，对 Agent 来说却造成了更糟糕的后果：它确认了这个草率的调用是正确的。Agent 在循环中唯一的训练信号就是你的工具返回的反馈。接受垃圾数据，你就在教导模型——就在此时此刻，在这个会话片段中——垃圾数据是行得通的。

十年来，无障碍（Accessibility）一直是那种被忽视的工作。它躺在待办事项（backlog）的最底层，只有在合规性审查期间才会浮出水面，然后被修补上刚好能让 linter 闭嘴的 ARIA 标签。经济层面的论据从未奏效，因为受影响的用户是少数群体，他们的流失从未出现在任何会让工程师收到告警（paged）的仪表盘上。

然后，浏览器代理（browser agents）出现了，经济逻辑在一夜之间发生了反转。像 ChatGPT 的浏览模式、Claude 的 computer use 以及基于 Playwright-MCP 的自动化浪潮，它们并不看你的像素。它们读取的是浏览器的“无障碍树”（accessibility tree）——这正是屏幕阅读器（screen readers）二十年来一直在消费的语义结构。每一个未标记的按钮、每一个伪装成链接的 div、每一个没有暴露状态的自定义下拉菜单，现在不仅对盲人用户不可见，对你的业务合作伙伴正在集成的代理也是不可见的。十年积压的无障碍债务变成了集成债务（integration debt），而集成债务是挂钩付费客户的。

你的团队在 2024 年拒绝了微服务拆分。当时开了一个两小时的会议，Slack 上的讨论异常激烈，还有一份对比运营成本的电子表格。结论是坚定的：在平台团队交付多区域部署之前，保持单体架构不变。当时在场的每一个人都还记得这件事。

你的编码 Agent 当时并不在场。上周二，它再次提议拆分——语气自信，带着一份干净的迁移计划和一份论据充分的设计文档。再上个周二，另一个 Agent 会话建议提取计费服务。下周，第三个 Agent 会建议用你评估过并两次拒绝的消息中间件来替换你定制的任务队列。就它们所能看到的信息而言，它们都没有错。它们只是看不到决策的价值所在，因为解决这些问题的推理过程存在于已过期的 Slack 线程、未记录的会议以及两名工程师的脑海中，而其中一人已经离职了。

这是 Agent 辅助工程的一种悄然发生的失败模式：已解决的问题正以机器速度被重新审议。而解决办法是大多数团队在十年前归类为“官僚主义、有则更好”的一项实践——架构决策记录（ADR）。

在 2025 年假期期间，AI 智能体驱动了全球约 20% 的电子商务订单——销售额约为 2620 亿美元。这个数字背后隐藏着一个更为奇怪的事实：这些订单所流经的支付基础设施，几乎没有一个是为非人类买家设计的。卡组织的整个信任模型——设备指纹、IP 地址、行为生物特征、“持卡人在场”信号——都假设交易的另一端是一个真人。当智能体结账时，这些信号要么缺失，要么是合成的。

行业的解决方案正以“委托层”的形式出现：通过加密签名的授权（mandates）来证明在软件下单之前，人类已经授权了该笔购买。但在协议发布与操作现实之间，存在着一系列尚未解决的问题，任何构建智能体结账（或通过其进行销售）的人都需要了解这些问题。其中最重要的问题目前还没有答案：当智能体买错了东西，损失由谁承担？

你的入职清单会筛选很多东西：背景调查、利益冲突披露、签署的知识产权转让协议、装有正确 MDM 配置的笔记本电脑。但它无法筛选新入职的资深工程师真正携带的东西——一个个人 AI 订阅账号，其记忆中包含了从前任雇主那里积累了 18 个月的上下文。架构争论、事故复盘、未发布的产品名称、他们刚花了两年时间构建的查询优化器的精确形态。这些不是他们窃取的文件，而是助手通过一次次对话吸收、在后台合成的环境上下文，当他们在入职新工作提问时，助手会很乐意调用这些信息。

同样的边界在员工离职时也会在另一个方向失效。当那名工程师离开你时，你的离职流程手册会撤销他们的 SSO、停用他们的 OAuth 令牌并擦除他们的笔记本电脑。但它不会——因为它无法——触及个人的 ChatGPT 或 Claude 账号，因为你的架构决策、事故历史和路线图现在作为记忆条目存在于一个你不拥有、无法审计且无法擦除的租户中。雇佣关系一直通过人类记忆泄露知识，而法律已经接受了这一点。新出现的是随人移动的第二种“机器级记忆”：它是可搜索的、持久的、在某些地方是逐字记录的，并且对过渡期两端的雇主都是不可见的。

如果你的 Agent 团队通过一个共享的计划文件、仓库或设计文档进行协作，每个人都在上面读写，那么恭喜你：你重新发明了黑板架构 (blackboard architecture)。这种架构在 1975 年曾是顶尖技术。令人尴尬的不是“重新发明”本身——好的想法值得回归。尴尬之处在于，原始架构有三个承重组件，而大多数现代 Agent 技术栈只重建了其中之一。

Hearsay-II 是 1971 年至 1976 年间在卡内基梅隆大学构建、由 DARPA 资助的语音理解系统。它面临着一个听起来很熟悉的问题：许多专业但不可靠的专家——声学分析器、语法预测器、语义评分器——没有一个能独立解决问题，它们都需要建立在彼此的局部推测之上。由此产生的架构包含一个共享工作区（黑板）、独立的专家（知识源）以及一个调度程序，调度程序在每一步决定接下来应该执行哪个专家的贡献。五十年后，将 LLM Agent 连接在一起的团队正趋向于同样的形态——一个主 Agent、一组执行者、一个共享产出物——并陷入了黑板架构文献在大多数人出生前就已命名并解决的失败模式。

你最高产的工程师刚刚递交了辞呈。你对这套流程已经烂熟于心：移交工单、记录部署流程、交接值班轮换、安排知识分享会议。这份离职核查清单经过了数十年的完善，涵盖了公司认为其拥有的一切资产。

以下是 2026 年的核查清单所遗漏的内容：那位工程师的家目录（home directory）中包含一个经过 18 个月调校的个人 CLAUDE.md 文件、十几个编码了如何处理最棘手子系统的自定义技能（skills）、存储了智能体积累的关于代码库难点事实的记忆文件，以及经过数百次尝试和错误校准的座架（harness）设置。这些都不在代码仓库中，也不会随账号一起移交。

在他们的最后一天，IT 部门停用了笔记本电脑，数月积累的智能体配置——这正是他们的智能体能独立交付功能而其他人的智能体却在挣扎的区别所在——在无人察觉的情况下蒸发了。

周五下午 4:50，数据团队的某人启动了一次评估扫描（eval sweep）：针对公司的共享模型部署运行四万个提示词，计划在周末完成。下午 5:10，面向客户的聊天助手开始超时。值班工程师盯着仪表盘看了两个小时，显示服务商返回了 429 错误，直到有人想起问一句还有谁在使用该账号。没有任何东西损坏。系统正完全按照配置运行，也就是说什么也没做，因为没人配置它去做任何事。

这是一种新型故障的雏形，它具有一个比普通停机更棘手的特性：没有需要修复的 Bug。评估扫描是正当的工作。聊天助手的流量也是正当的工作。失败之处在于，两个具有不同紧急程度的团队从一个无差别的推理算力池中提取资源，而该池子对谁更重要没有任何判断。当你的公司有多个团队同时使用同一个服务商账号时，容量分配就不再仅仅是基础设施的细节——它变成了一个政治问题，而传呼机（pager）继承了这一麻烦。

关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。

数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。