2026 年，在 AI Agents 里该学什么、该构建什么、又该跳过什么

2026 年，在 AI Agents 里该学什么、该构建什么、又该跳过什么 2026 年，在 AI Agents 里该学什么、该构建什么、又该跳过什么 Modified May 1 你本周在 Hacker News 上看到的下一个框架 等六个月。 如果它真的重要，到时候会很明显。 如果它不重要，你就省掉了一次迁移。 真正该怎么动起来 如果你是想真正采用 agent，而不是只是“追踪 agent 领域动向”，下面这个顺序是有效的。 它很无聊。 但它真的有效。 先选一个已经对业务重要的结果。 不是登月项目。不是某种横向 agent 平台项目。而是一个本来就已经被业务指标定义清楚的结果。 比如： 减少客服工单、起草第一版法务审查、筛选主动流入的销售线索、生成月报。 Agent 成功与否，取决于这个结果有没有动。 它从第一天起，就是你的评测目标。 为什么这一步比其他所有步骤都更重要？ 因为它会约束你后面所有决定。 当你有了一个具体结果： “该选哪个框架”就不再是哲学问题，而是哪个能最快把结果做出来。 “该选哪个模型”也不再是基准测试争论，而是哪个在你自己的评测上表现更好。 “我们要不要记忆 / 子代理 / 自定义承载层”也不再是思想实验，而是看你是否真的遇到了对应失败模式。 跳过这一步的团队，最后总会去构建某种没人点名要的横向平台。 认真做了这一步的团队，最后通常会先交付出一个非常窄、但能在一个季度内自我回本的 agent。 而这一个 agent 给他们带来的学习，胜过看两年文章。 在你真正上线任何东西之前，就把链路追踪和评测接好。 选 Langfuse 或 LangSmith。 先接进去。 没有数据集，就手工先做一个小型黄金数据集。 50 个带标签的例子就足够起步。 你无法改进你不能测量的东西。 而后面补这件事的成本，通常是现在做好的十倍。 从单代理循环开始。 选 LangGraph 或 Pydantic AI。 模型选 Claude Sonnet 4.6 或 GPT 5。 给 agent 3 到 7 个设计良好的工具。 把文件系统或数据库给它作为 state。 先向小范围用户发出去。 然后观察链路。 把 agent 当作一个产品，而不是一个项目。 它一定会以你没预料过的方式失败。 而这些失败，就是你的路线图。 从真实生产链路里构建回归测试集合。 每次 prompt 变更、模型切换、工具变更，在部署前都先跑评测。 这是大多数团队最少投入的地方。 也是大多数可靠性真正产生的地方。 只有在你“赚到了”更大范围的时候，才给它加范围。 子代理是在上下文真正成为瓶颈时才引入。 记忆框架是在单窗口上下文真的装不下你需要的东西时才引入。 Computer use 或 browser use，是在底层 API 真正不存在时才引入。 不要预先为这些场景做架构。 让失败模式把它们拉进来。 选无聊的基础设施。 MCP 做工具层。E2B 或 Browserbase 做沙箱。状态层用你本来就已经在跑的 Postgres 或现有存储。鉴权和可观测性继续沿用你自己的那套。 稀奇的基础设施很少真正赢。 真正赢的是纪律。 从第一天就盯住单位经济模型。 每次 action 的成本。缓存命中率。重试循环的成本。模型调用的分布。 agent 在概念验证阶段看起来都很便宜，但只要规模涨到 100 倍，如果你没有从一开始就把“每个结果的成本”打清楚，它就会失控。 一个每次运行 0.5 美元的概念验证，在中等流量下就会变成每月 5 万美元。 没有提前看见这一点的团队，最后通常会被 CFO 拉去开一个他们非常不想开的会。 按季度重评模型，不要按周重评。 一个季度内锁定下来。 季度结束时，用你的评测集跑一遍当前前沿模型，如果数据告诉你该换，再换。 这样你能吃到模型进步的红利，同时避免被每次发布拖进混乱里。 如何读懂潮水方向 下面这些，是某样东西更像信号的具体征兆： 一个你尊重的工程团队，写了带数字的复盘，而不是只说“我们用了它”。 它是一个基础单元，比如协议、模式或基础设施，而不是某种封装层或打包组合。 它能和你现在已经在运行的东西互操作，而不是要求把它们替换掉。 它描述的是“它解决了什么失败模式”，而不是空泛地说“它能做什么能力”。 它已经存活得足够久，长到已经有人写出一篇“哪些地方没成功”的文章。 而这些，通常是某样东西更像噪音的征兆： 发布 30 天以后仍然没有生产案例，只剩演示视频。 基准测试数字好看到失真。 叙事里疯狂使用 autonomous、agent OS、build any agent 这类词，却没有限定条件。 文档默认你要扔掉现有链路追踪、鉴权和配置。 GitHub star 飞涨，但提交、发布和贡献者数量没有一起涨。 Twitter 的热度在跑，但 GitHub 没有对应速度。 一个非常实用的每周习惯是： 周五拿出 30 分钟，专门给这个领域。 读三样东西： Anthropic 的工程博客。Simon Willison 的笔记。Latent Space。 如果这周恰好有复盘，再额外扫一两篇。 其他的，全都跳过。 你仍然会知道真正重要的事。 值得观察什么 未来两个季度，有些东西值得保持注意力。 不是因为它们一定会赢。 而是因为“这到底是不是信号”这个问题，还没有彻底解出来。 Replit Agent 4 的并行分叉模型 这是第一次比较严肃地尝试“多个 agent 并行工作”，同时又不直接踩进共享状态地雷。 如果它在规模上真的能成立，那么总控代理 子代理这套默认形状，也许会改变。 按结果计费（Outcome based Pricing）的成熟度 Sierra 和 Harvey 的收入曲线，已经在狭窄垂直领域里验证了这条路。 接下来真正值得看的，是： 它能不能走出垂直领域，还是会永远停留在垂直赛道里。 Skills 作为封装层（Packaging Layer） AGENTS.md 和各种 skills 目录，在 GitHub 上的扩散，已经暗示出一种新形式： agent 能力也许会出现一种像 MCP 对工具那样的标准化封装方式。 这个问题还没有答案。 Claude Code 在 2026 年 4 月的质量回退，以及它的复盘 一个行业领先的 agent，发布了 47% 的性能回退，而且是用户先发现，内部监控后发现。 这本质上是在告诉你： 就算是这个行业最前面的团队，生产级 agent 评测也还远远不成熟。 如果这次事故最终能推动全行业开始认真投入在线评测，那这个修正本身反而是健康的。 Voice 成为默认的支持界面 Sierra 的 voice channel 在 2025 年末已经超过了 text。 如果这个趋势在其他垂直领域继续成立，那么： 延迟、打断、实时工具调用 这些就会变成第一序设计约束。 而大量当前的系统架构，都会因此必须重做。 开源模型的 Agent 能力不断逼近 DeepSeek V3.2 已经把 thinking 与 tool use 结合得更自然。 Qwen 3.6 也在往前推。 整个开源生态的成本 性能比，在窄 agent 任务上还在快速变化。 闭源默认解，并不是永久的。 这些方向都有一个非常清楚的追问： “六个月后，我要看到什么证据，才会相信它成立？” 这才是应该跟踪的东西。 跟踪答案，而不是跟踪公告。 那个最不传统的下注 你本周在 Hacker News 上看到的下一个框架 等六个月。 如果它真的重要，到时候会很明显。 如果它不重要，你就省掉了一次迁移。 真正该怎么动起来 如果你是想真正采用 agent，而不是只是“追踪 agent 领域动向”，下面这个顺序是有效的。 它很无聊。 但它真的有效。 先选一个已经对业务重要的结果。 不是登月项目。不是某种横向 agent 平台项目。而是一个本来就已经被业务指标定义清楚的结果。 比如： 减少客服工单、起草第一版法务审查、筛选主动流入的销售线索、生成月报。 Agent 成功与否，取决于这个结果有没有动。 它从第一天起，就是你的评测目标。 为什么这一步比其他所有步骤都更重要？ 因为它会约束你后面所有决定。 当你有了一个具体结果： “该选哪个框架”就不再是哲学问题，而是哪个能最快把结果做出来。 “该选哪个模型”也不再是基准测试争论，而是哪个在你自己的评测上表现更好。 “我们要不要记忆 / 子代理 / 自定义承载层”也不再是思想实验，而是看你是否真的遇到了对应失败模式。 跳过这一步的团队，最后总会去构建某种没人点名要的横向平台。 认真做了这一步的团队，最后通常会先交付出一个非常窄、但能在一个季度内自我回本的 agent。 而这一个 agent 给他们带来的学习，胜过看两年文章。 在你真正上线任何东西之前，就把链路追踪和评测接好。 选 Langfuse 或 LangSmith。 先接进去。 没有数据集，就手工先做一个小型黄金数据集。 50 个带标签的例子就足够起步。 你无法改进你不能测量的东西。 而后面补这件事的成本，通常是现在做好的十倍。 从单代理循环开始。 选 LangGraph 或 Pydantic AI。 模型选 Claude Sonnet 4.6 或 GPT 5。 给 agent 3 到 7 个设计良好的工具。 把文件系统或数据库给它作为 state。 先向小范围用户发出去。 然后观察链路。 把 agent 当作一个产品，而不是一个项目。 它一定会以你没预料过的方式失败。 而这些失败，就是你的路线图。 从真实生产链路里构建回归测试集合。 每次 prompt 变更、模型切换、工具变更，在部署前都先跑评测。 这是大多数团队最少投入的地方。 也是大多数可靠性真正产生的地方。 只有在你“赚到了”更大范围的时候，才给它加范围。 子代理是在上下文真正成为瓶颈时才引入。 记忆框架是在单窗口上下文真的装不下你需要的东西时才引入。 Computer use 或 browser use，是在底层 API 真正不存在时才引入。 不要预先为这些场景做架构。 让失败模式把它们拉进来。 选无聊的基础设施。 MCP 做工具层。E2B 或 Browserbase 做沙箱。状态层用你本来就已经在跑的 Postgres 或现有存储。鉴权和可观测性继续沿用你自己的那套。 稀奇的基础设施很少真正赢。 真正赢的是纪律。 从第一天就盯住单位经济模型。 每次 action 的成本。缓存命中率。重试循环的成本。模型调用的分布。 agent 在概念验证阶段看起来都很便宜，但只要规模涨到 100 倍，如果你没有从一开始就把“每个结果的成本”打清楚，它就会失控。 一个每次运行 0.5 美元的概念验证，在中等流量下就会变成每月 5 万美元。 没有提前看见这一点的团队，最后通常会被 CFO 拉去开一个他们非常不想开的会。 按季度重评模型，不要按周重评。 一个季度内锁定下来。 季度结束时，用你的评测集跑一遍当前前沿模型，如果数据告诉你该换，再换。 这样你能吃到模型进步的红利，同时避免被每次发布拖进混乱里。 如何读懂潮水方向 下面这些，是某样东西更像信号的具体征兆： 一个你尊重的工程团队，写了带数字的复盘，而不是只说“我们用了它”。 它是一个基础单元，比如协议、模式或基础设施，而不是某种封装层或打包组合。 它能和你现在已经在运行的东西互操作，而不是要求把它们替换掉。 它描述的是“它解决了什么失败模式”，而不是空泛地说“它能做什么能力”。 它已经存活得足够久，长到已经有人写出一篇“哪些地方没成功”的文章。 而这些，通常是某样东西更像噪音的征兆： 发布 30 天以后仍然没有生产案例，只剩演示视频。 基准测试数字好看到失真。 叙事里疯狂使用 autonomous、agent OS、build any agent 这类词，却没有限定条件。 文档默认你要扔掉现有链路追踪、鉴权和配置。 GitHub star 飞涨，但提交、发布和贡献者数量没有一起涨。 Twitter 的热度在跑，但 GitHub 没有对应速度。 一个非常实用的每周习惯是： 周五拿出 30 分钟，专门给这个领域。 读三样东西： Anthropic 的工程博客。Simon Willison 的笔记。Latent Space。 如果这周恰好有复盘，再额外扫一两篇。 其他的，全都跳过。 你仍然会知道真正重要的事。 值得观察什么 未来两个季度，有些东西值得保持注意力。 不是因为它们一定会赢。 而是因为“这到底是不是信号”这个问题，还没有彻底解出来。 Replit Agent 4 的并行分叉模型 这是第一次比较严肃地尝试“多个 agent 并行工作”，同时又不直接踩进共享状态地雷。 如果它在规模上真的能成立，那么总控代理 子代理这套默认形状，也许会改变。 按结果计费（Outcome based Pricing）的成熟度 Sierra 和 Harvey 的收入曲线，已经在狭窄垂直领域里验证了这条路。 接下来真正值得看的，是： 它能不能走出垂直领域，还是会永远停留在垂直赛道里。 Skills 作为封装层（Packaging Layer） AGENTS.md 和各种 skills 目录，在 GitHub 上的扩散，已经暗示出一种新形式： agent 能力也许会出现一种像 MCP 对工具那样的标准化封装方式。 这个问题还没有答案。 Claude Code 在 2026 年 4 月的质量回退，以及它的复盘 一个行业领先的 agent，发布了 47% 的性能回退，而且是用户先发现，内部监控后发现。 这本质上是在告诉你： 就算是这个行业最前面的团队，生产级 agent 评测也还远远不成熟。 如果这次事故最终能推动全行业开始认真投入在线评测，那这个修正本身反而是健康的。 Voice 成为默认的支持界面 Sierra 的 voice channel 在 2025 年末已经超过了 text。 如果这个趋势在其他垂直领域继续成立，那么： 延迟、打断、实时工具调用 这些就会变成第一序设计约束。 而大量当前的系统架构，都会因此必须重做。 开源模型的 Agent 能力不断逼近 DeepSeek V3.2 已经把 thinking 与 tool use 结合得更自然。 Qwen 3.6 也在往前推。 整个开源生态的成本 性能比，在窄 agent 任务上还在快速变化。 闭源默认解，并不是永久的。 这些方向都有一个非常清楚的追问： “六个月后，我要看到什么证据，才会相信它成立？” 这才是应该跟踪的东西。 跟踪答案，而不是跟踪公告。 那个最不传统的下注 每一个你没有采用的框架，都是一次你不必背负的迁移。 每一个你没有追的基准测试，都是一整个季度还能留在你手里的专注力。 这一轮真正赢下来的公司，在各自领域里像 Sierra、Harvey、Cursor 那样的团队，共同点都不是“追得快”。 而是： 选得窄，纪律足够无聊，并且让外界噪音自然从自己身边流过去。 传统路径是： 选一个技术栈，花多年把它练熟，然后沿着梯子往上爬。 当技术栈十年不怎么变时，这条路径是成立的。 但现在，技术栈每个季度都在变。 真正赢的人，已经不再优化自己对某个技术栈的精熟度。 他们开始优化的是： 判断力、基础单元、交付速度。 他们会公开把小东西做出来。他们通过发布来学习。他们靠已经做出的东西被拉进新的机会。他们的 credential 就是 artifact 本身。 你最好在这里停一下。 因为这其实就是整篇文章真正的重点。 我们大多数人，从小被训练的是一种默认世界观： 世界会静止得足够久，长到你靠 credential 就能复利。 你去上学。你拿到学位。你爬梯子。两年这里、三年那里，慢慢把简历堆成一张能开门的通行证。 这整台机器的前提，是外面的行业本身相对稳定。 而 agent 这个领域，现在根本没有那个稳定的“外面”。 你想去的公司，也许刚成立六个月。 它们依赖的框架，也许只有十八个月历史。 底层 protocol，也许只有两年。 这个领域里被引用最多的一半文章，作者三年前甚至都还没在这个领域里。 当梯子本身失效时，剩下的就只剩那种更古老的方法： 做一个东西。把它放到互联网上。让作品自己替你做介绍。 它之所以是“非传统路径”，恰恰因为它绕开了 credential 体系。 而在一个底层持续运动的领域里，它也是唯一真正会复利的路径。 这就是从内部看这个时代的样子。 原帖链接：https://x.com/rohit4verse/status/2049548305408131349 原帖链接：https://x.com/rohit4verse/status/2049548305408131349 每天都会冒出一个新框架、一个新基准测试、一个新的“10x”发布。 问题已经不再是“我该怎么跟上”。 而是： 这里面到底哪些是真正的信号，哪些只是披着紧迫感外衣的噪音？ 每一张路线图，发布一个月后就开始过时。 你上个季度刚学熟的框架，这个季度就可能成了遗留方案。 你之前为之优化的基准测试，也许已经被刷榜、被玩坏，然后被替换掉。 我们曾经被训练成遵循一条很传统的路径： 一套按主题和层级划分的技术栈，一串逐级上升的岗位与年限，一条缓慢但稳定的爬坡路线。 AI 把这张画布整个重写了。 现在，任何一个手里拿着合适的 prompt，再加上一点判断力的人，都能交付出过去需要一位有两年经验的工程师花一个迭代周期才能完成的工作。 专业能力依然重要。 没有什么能替代： 看着系统在你面前崩掉过，凌晨两点亲手排查过内存泄漏，在“聪明但花哨”的方案和“无聊但稳”的方案之间争论过，并最终证明自己是对的。 这种判断力会持续复利。 但有一样东西，已经不再像过去那样持续复利了： 那就是你对“本周这个框架的接口细节”有多熟。 六个月后，它大概率已经变了。 那些会在两年后真正赢下来的人，往往很早就抓住了耐用的基础单元，然后让其他噪音从自己身边飘过去。 我在这个领域已经做了两年，拿到过多个 25 万美元以上的 offer，现在在一家隐身模式公司负责技术。 如果有人来问我： “我现在到底该真正关注什么？” 这就是我会发给他的东西。 这不是一张路线图。 因为 agent 这个领域现在根本还没有终点。 大实验室都还在公开迭代，在几百万用户面前发布性能回退、写复盘、边跑边修。 如果连 Claude Code 背后的团队，都能发布一次 47% 的性能回退，而且还是用户社区先发现、他们后确认，那就说明：以为这一切底下已经有一张稳定地图，这件事本身就是幻想。 所有人都还在摸索。 创业公司之所以还能繁荣，就是因为那些巨头自己也还不知道最终答案。 非程序员也在和 agent 搭档，然后在周五交付出某种东西，而机器学习博士们在周二时还在说这“不可能”。 这个时刻真正有趣的地方，在于它重新定义了“资历”这件事。 传统路径优化的是资历： 学历、初级岗位、高级岗位、Staff 岗位，以及头衔的缓慢积累。 当底层领域本身不怎么变化时，这条路径是有意义的。 但现在，底层领域在所有人脚下都在移动。 一个 22 岁、公开发布 agent 演示的年轻人，和一个 35 岁的资深工程师之间，不再只是相差十年技术积累。 因为那个 22 岁的人，和资深工程师一样，面对的是同一块空白画布。 而真正会持续积累的，只剩下： 愿意持续交付的意志，以及那一小撮不会在一个季度内过时的基础单元。 这就是整篇文章的重构前提。 接下来要讲的，就是一种判断方式： 哪些基础单元值得你把注意力投进去，哪些发布应该直接放过去。 适合你的就拿走。 不适合的就留在这里。 真正有效的过滤器 你不可能跟上每周的所有发布。 你也不应该去试。 你真正需要的不是更多信息流。 你需要的是一个过滤器。 过去 18 个月里，有 5 个测试一直有效。 每次新东西发布时，都先让它过这 5 道关，再决定要不要让它碰你的技术栈。 1. 这东西两年后还会重要吗？ 如果它只是一个前沿模型的封装层、一个命令行开关，或者某种“Devin but for X”，答案几乎总是否。 如果它是一个基础单元，比如协议、记忆模式或沙箱方案，答案更可能是“会”。 封装层的半衰期很短。 基础单元的半衰期往往按年计算。 2. 有没有你尊重的人，真的拿它做出过真实东西，并且诚实写过过程？ 营销帖不算。 复盘才算。 一篇叫做“我们把 X 用进了生产环境，结果这些地方坏了”的文章，价值顶得上十篇发布公告。 这个领域里最好的信号，永远来自那些真的被它坑掉过一个周末的人。 3. 用它，是否意味着你要把链路追踪、重试机制、配置、鉴权全部扔掉重来？ 如果答案是“要”，那它大概率是一个“试图把自己包装成平台的框架”。 这种框架的死亡率高得惊人。 真正好的基础单元，应该能插进你已有系统里，而不是逼你迁移整个平台。 4. 如果未来 6 个月我完全跳过它，会损失什么？ 对大多数发布来说，答案其实是： 什么也不会损失。 六个月后你会知道得更多。 胜出的版本会更清晰。 这是让你能够毫无焦虑地跳过 90% 发布的那个测试。 也是大多数人最不愿意做的那个测试，因为“跳过”会让人误以为自己在落后。 其实不是。 5. 你能测量它到底有没有真正提升你的 agent 吗？ 如果不能，那你只是在猜。 没有评测体系的团队，只能靠感觉行事，并持续把性能回退发出去。 有评测体系的团队，才能真正用数据来判断：这一周，GPT 5.5 还是 Opus 4.7，在我们的具体任务负载上表现更好？ 如果你只从整篇文章里带走一个习惯，那就带走这个： 每当有新东西发布时，写下： “六个月后，我需要看到什么证据，才会相信它真的重要？” 然后六个月后回来核对。 大多数时候，这个问题会自动回答自己。 而你也会把注意力花在那些真正能复利的东西上。 在这 5 个测试底下，还有一种更难命名的能力。 那就是： 愿意在自己不去学某些东西时，依然心安理得。 本周在 Hacker News 爆红的框架，会有一群啦啦队为它欢呼十四天，而且他们看起来都会很聪明。 六个月后，其中一半会无人维护，而那群欢呼者也早就换了下一个话题。 那些没有加入其中的人，反而把注意力留给了真正活过炒作周期的东西。 这种姿态： 按住自己，先看着，然后说“六个月后我再判断”， 这其实才是这个行业真正的专业能力。 所有人都会读发布公告。 几乎没有人真的擅长“不对发布立即做出反应”。 该学什么 学概念。学模式。学事物背后的形状。 这些东西会持续复利。 它们能在模型更换、框架更换、范式迁移之后继续成立。 你把这些学透了，就能在一个周末内捡起任何新工具。 如果你跳过它们，你就会永远处在“不断重学表层操作”的循环里。 上下文工程（Context Engineering） 过去两年里最重要的一次改名，就是 “prompt engineering” 变成了 “context engineering”。 这个变化不是表面修辞。 它是真的。 模型不再是一个你只需要给它写一句聪明指令的东西。 它变成了一个你必须在每一步都替它装配好工作上下文的系统。 这个上下文同时包含： system instruction、tool schema、retrieved document、prior tool output、scratchpad state、被压缩过的历史。 Agent 的行为，本质上就是这些上下文拼装后的涌现结果。 把这句话彻底内化： context 就是 state。 每一个和任务无关的 token，都会真实拉低推理质量。 上下文腐坏是一种非常真实的生产故障。 到了一个 10 步任务的第 8 步时，最初目标往往已经埋在一堆工具输出下面了。 真正能把 agent 做可靠的团队，会主动： 总结、压缩、裁剪。 他们会给工具说明做版本管理。 他们会缓存静态部分，同时拒绝缓存会变化的部分。 他们看待上下文窗口的方式，就像一个有经验的工程师看待内存一样。 如果你想真正感受到这一点，一个很具体的做法是： 对任何已经在生产里的 agent，打开完整的链路日志。 看看第 1 步的上下文。 再看看第 7 步的上下文。 数一数这些 token 里，到底有多少还在继续为结果“打工”。 你第一次这么做时，通常会感到尴尬。 然后你会回去修它。 修完之后，同一个 agent 的可靠性会明显提升，而你甚至没有改模型，也没有改 prompt。 如果你只读一篇关于这个主题的东西，那就去读 Anthropic 的“Effective Context Engineering for AI Agents”。 然后再去读他们关于多代理的研究复盘，那里面把“为什么上下文隔离会在规模上变得重要”直接量化了出来。 工具设计（Tool Design） 工具是 agent 和你业务真正相接触的地方。 模型根据工具的名字和描述来选工具。 模型根据错误信息来决定要不要重试。 模型的成败，很大程度上取决于工具契约是否与 LLM 天生擅长表达的方式契合。 5 到 10 个命名清晰的工具，胜过 20 个平庸工具。 工具名称应该像自然语言里的动词短语。 描述里应该写明： 什么时候该用，什么时候不该用。 错误信息应该是模型能够真正拿来行动的反馈。 “Max tokens 500 exceeded, try summarizing first”和“Error: 400 Bad Request” 这两者之间的实际差距大得惊人。 有公开研究团队报告说，他们仅仅重写了错误信息，就把重试循环降低了约 40%。 Anthropic 的 “Writing tools for agents” 是这个主题最好的起点。 读完之后，去给你自己的工具加上埋点，看看它们真实的调用模式。 agent 可靠性最大的提升，几乎永远发生在工具这一侧。 很多人不停调 prompt，却无视了真正有杠杆的位置。 总控代理 子代理模式（Orchestrator Subagent Pattern） 2024 和 2025 年关于多代理的争论，最后收敛成了一个现在几乎所有人都在用的综合答案。 那种天真的多代理系统，也就是多个 agent 并行写共享状态的模式，在生产里会灾难性失败，因为错误会指数叠加。 真正能扩展得比你想象中更远的，往往是单代理循环。 而现在唯一被证明在生产里可靠的多代理形状，是： 一个总控代理，把狭窄且只读的任务委派给被隔离开的子代理，然后再综合它们的结果。 Anthropic 的研究系统是这么工作的。 Claude Code 的 subagent 也是这么工作的。 Spring AI 以及大多数生产框架现在标准化的，都是这个模式。 子代理拿到的是小而专注的上下文。 它们不能直接改共享状态。 真正拥有写权限的，只有总控代理。 Cognition 的 “Don't Build Multi Agents” 和 Anthropic 的 “How we built our multi agent research system” 看上去像是在唱反调。 其实它们在不同词汇里，说的是同一件事。 把两篇都读了。 默认从单代理开始。 只有当单代理真正撞墙时，再上总控代理 子代理： 比如上下文窗口压力、串行工具调用带来的高延迟、或者任务异质性已经大到必须拆分专注上下文。 在你真正感受到痛之前，就提前把这个复杂度架起来，基本只是在给自己增负担。 评测体系与黄金数据集（Evals and Golden Dataset） 每一个真正把 agent 做可靠的团队，都有评测体系。 每一个没有的团队，最后都没有。 这是整个领域里杠杆最高的习惯。 也是我在每家公司里看到的，投入最不足的一件事。 真正有效的方法是： 从生产链路里抓样本，把失败样本标出来，然后把它们当作你的回归测试集合。 每当新的失败漏出来，就把它加进去。 主观部分用 LLM as judge。其余部分用精确匹配或程序化检查。 任何 prompt、模型或工具变更上线前，都先跑一遍这套集合。 Spotify 的工程博客曾提到，他们的评判层会在输出真正发给用户前，拦下大约 25% 的结果。 如果没有那一层，那么四分之一的坏结果就会直接到用户面前。 真正能让这件事扎根的心智模型是： eval 就是 agent 时代的单元测试。 它的作用，是在一切底层都不断变化时，帮你维持系统的诚实性。 模型换版本了。框架发 breaking change 了。供应商下掉了一个 endpoint。 而评测体系是唯一能告诉你： 你的 agent 还在不在正确做它该做的事。 没有评测体系，你等于在写一个正确性依赖于“移动目标的善意”的系统。 Braintrust、Langfuse evals、LangSmith，这些框架本身都够用了。 它们都不是瓶颈。 真正的瓶颈，是你一开始有没有标注数据集。 这件事第一天就做。 在你打算扩任何东西之前就做。 最初 50 个例子，花一个下午手工标完就够起步了。 没有任何借口。 以文件系统为状态，以及“思考 行动 观察”循环 对于任何真的在做多步工作的 agent，最耐用的架构都是： 思考、行动、观察、重复。 再加上： 文件系统或某种结构化存储作为事实来源。每一步 action 都能被记录和 replay。 Claude Code、Cursor、Devin、Aider、OpenHands、goose。 它们之所以最后都收敛到这套模式，不是巧合。 模型本身是无状态的。 承载层必须是有状态的。 而文件系统，就是每个开发者都早已熟悉的一种有状态基础单元。 一旦你接受了这个框架，后面整套承载层纪律： 检查点、可恢复性、子代理验证、沙箱执行， 都会顺理成章地从这个模式里推导出来。 它更深一层真正教你的东西是： 对于任何一个真正值得它计算成本的生产 agent 来说，干更多活的往往是承载层，而不是模型。 模型负责选下一步 action。 承载层负责： 验证它、在 sandbox 里运行它、捕获输出、决定哪些内容回灌给模型、决定什么时候停止、决定什么时候打检查点、决定什么时候拉起子代理。 如果你把模型换成另一个同量级的模型，一个好的承载层仍然能继续稳定交付。 但如果你把承载层换成更差的版本，那么就算是世界上最好的模型，也只会产出一个会随机忘记自己在干什么的 agent。 如果你在构建的东西，已经比一次单发单回的工具调用更复杂，那么你真正应该花时间的地方，就是承载层。 模型只是它里面的一个组件。 MCP，作为概念来理解 不要只学“怎么调用 MCP server”。 去学它背后的模型。 一个关于 agent 能力、工具和资源的干净分层； 以及在它们底下，那套可扩展的鉴权和传输机制。 一旦你真正理解了这个模型，以后你看到的很多“agent 集成框架”，都会显得像 MCP 的低配版。 这会替你省掉大量本来没必要做的评估时间。 Linux Foundation 现在已经在托管它。 几乎所有主要模型提供方也都在支持它。 “AI 时代的 USB C” 这个比喻，现在已经不是调侃，而是非常接近现实。 沙箱机制，作为基础单元来理解 每一个生产级 coding agent 都跑在 sandbox 里。 每一个 browser agent 都遭遇过间接 prompt 注入。 每一个多租户 agent，都在某个时间点发出过权限范围错误。 要把沙箱机制当成基础设施级的基础单元来看， 而不是某个客户提出来之后你再去补的“功能”。 至少把这些基础学会： 进程隔离、网络出口控制、密钥作用域、agent 和工具之间的鉴权边界。 那些等到客户安全审查来了才开始补这些东西的团队，最后往往会丢单。 而从第一天就把这些打进系统里的团队，在走企业采购流程时会轻松很多。 该拿什么来构建 下面是 2026 年 4 月的具体选择。 它们以后会变化，但不会一夜之间大变。 所以，在这里，选“无聊”的方案是对的。 编排层（Orchestration） LangGraph 是现在默认的生产级选项。 大约三分之一真正把 agent 跑进大公司里的团队，都在用它。 它的抽象方式和真实生产 agent 的形状是匹配的： typed state、conditional edge、durable workflow、human in the loop checkpoint。 缺点是它比较啰嗦。 但好处恰恰也在这里： 这份啰嗦，对应的正是那些一旦 agent 进入生产，你真正必须掌控住的东西。 如果你主要生活在 TypeScript 世界里，Mastra 是那个生态下默认的选择。 它有最干净的心智模型。 如果你的团队非常依赖 Pydantic，而且希望类型安全成为第一公民，那么 Pydantic AI 是一个合理的绿地项目选择。 它在 2025 年末到达了 v1.0，势头也是真的起来了。 对于 provider native 的工作，比如 computer use、voice、real time，可以把 Claude Agent SDK 或 OpenAI Agents SDK 放在你的 LangGraph 节点里使用。 但不要试图让它们成为异构系统的顶层总控代理。 它们都只是在自己的赛道上非常好。 协议层（Protocol Layer） MCP。 没有第二个答案。 把你的工具集成都构建成 MCP server。 外部集成也按同样方式消费。 现在的注册表已经成熟到一个程度： 大多数时候，在你准备自己写一个 server 之前，你几乎总能先找到一个已有的。 2026 年再去自己手搓一套自定义工具管线，基本只是无谓缴税。 记忆层（Memory） 按自主等级来选，不要按热度来选。 Mem0 适合那种聊天式的个性化场景，比如用户偏好和轻量历史。 Zep 适合生产级对话系统，尤其是状态持续演化、而且你需要实体追踪的时候。 Letta 适合那种需要 agent 在数天或数周的工作跨度中保持一致性的场景。 大多数团队其实根本用不到这一层。 但真正需要的人，恰恰需要的就是这种东西。 最常见的错误，是在你还没有记忆问题的时候，就先去上记忆框架。 一开始先用上下文窗口加向量存储。 只有在你能清楚说出： “我要解决的失败模式到底是什么” 之后，再加记忆系统。 可观测性与评测（Observability and Evals） Langfuse 是开源默认选项。 可自托管、MIT 许可证，覆盖链路追踪、prompt 版本管理，以及基础的 LLM as judge 评测。 如果你已经是 LangChain 体系，那 LangSmith 会集成得更紧。 如果你更偏研究式评测工作流，且需要更严谨的对比流程，Braintrust 是更合适的选择。 如果你的系统是多语言、多运行时，并且你需要供应商中立的 OpenTelemetry 埋点，那 OpenLLMetry / Traceloop 更合适。 你真正需要的是： 链路追踪和评测两者都要有。 链路追踪回答的是： “agent 到底做了什么？” 评测回答的是： “它今天比昨天更好还是更差？” 这两者缺一个，都不应该上线。 带着盲区去运行系统的成本，是第一天把这套东西正确接好的十倍。 运行时与沙箱（Runtime and Sandbox） E2B 适合通用的沙箱代码执行。 Browserbase 配合 Stagehand，适合浏览器自动化。 Anthropic Computer Use 适合那种真正需要操作系统级桌面控制的场景。 Modal 适合短时突发任务。 不要让 agent 跑未经过沙箱隔离的代码执行。 永远不要。 一个被 prompt 注入污染的 agent，在你生产环境里的影响范围，会变成一个你绝对不想复盘的故事。 模型（Models） 追基准测试这件事已经很累了，而且大多数时候没有意义。 更实际一点，在 2026 年 4 月： Claude Opus 4.7 和 Sonnet 4.6，适合稳定工具调用、多步一致性，以及优雅失败恢复。 Sonnet 基本是大多数任务负载下性价比最好的甜点位。 GPT 5.4 和 5.5，适合命令行 / 终端推理特别强的场景，或者你本来就深度生活在 OpenAI 基础设施里。 Gemini 2.5 和 3，适合特别吃长上下文或特别吃多模态的任务。 DeepSeek V