编者按：AI Agent 领域正在进入一个工具爆炸、共识不足的阶段。

每周都有新框架、新模型、新 benchmark 和新的「10 倍效率」产品出现，但真正重要的问题，已经不是「如何跟上所有变化」，而是「哪些变化真的值得投入」。

作者认为，在技术栈不断被重写的当下，真正能长期复利的不是追逐最新框架，而是更底层的能力：context engineering、工具设计、eval 体系、orchestrator-subagent 模式、沙盒与 harness 思维。这些能力不会随着模型换代迅速失效，反而会成为构建可靠 AI Agent 的基础。

文章更进一步指出，AI Agent 也在改变「资历」的含义。过去，学历、职级和年限是进入行业的通行证；但在一个连巨头都还在公开试错的领域里，简历不再是唯一凭证。你做出了什么、交付了什么，正在变得更重要。

因此，本文不只是讨论 2026 年 AI Agent 该学什么、用什么、跳过什么，更是在提醒：在噪音越来越多的时代，最稀缺的能力，是判断什么值得学，并持续做出真正有用的东西。

以下为原文：

每天都会冒出一个新框架、一个新基准、一个新的「10 倍效率」产品。问题不再是「我该怎么跟上」，而是：这里面到底什么是真信号，什么只是披着紧迫感外衣的噪音。

每一份路线图，发布一个月后就可能过时。你上个季度刚掌握的框架，现在已经成了旧东西。你曾经为之优化的 benchmark，被人刷穿之后很快又被新的取代。过去，我们被训练成沿着一条传统路径前进：一个技术栈，对应一组主题和层级；一串工作经历，对应年限和头衔；一步一步缓慢往上爬。但 AI 改写了这张画布。今天，只要提示词用得对、审美判断足够好，一个人就能交付过去需要一名有两年经验的工程师花一个 sprint 才能完成的工作。

专业能力依然重要。没有什么可以替代你亲眼见过系统崩掉，凌晨两点调过内存泄漏，也没有什么能替代你曾经力排众议选择一个无聊但正确的方案，并最终被证明是对的。这样的判断力会复利增长。但不再像过去那样复利增长的，是你对「本周热门框架 API 表面」的熟悉程度。六个月后，它可能又变了。两年后真正胜出的人，是那些早早选中耐用基础能力、并让其他噪音从身边经过的人。

过去两年，我一直在这个领域构建产品，拿到过多个年薪 25 万美元以上的 offer，现在在一家隐身公司负责技术。如果有人问我：「现在到底应该关注什么？」这就是我会发给他的内容。

这不是一张路线图。Agent 领域还没有明确目的地。大厂实验室也在公开迭代，把回归问题直接推给数百万用户，再写复盘、在线修补。如果 Claude Code 背后的团队都能发布一个造成 47% 性能回退的版本，而且直到用户社区发现后才意识到问题，那么所谓「底下存在一张稳定地图」的想法就是虚构的。所有人都还在摸索。创业公司之所以有机会，正是因为巨头也不知道答案。不会写代码的人正在和 agent 搭档，在周五交付一些周二还被机器学习博士认为不可能的东西。

这个时刻最有意思的一点，是它改变了我们对「资历」的理解。传统路径优化的是资历：学位、初级岗位、高级岗位、资深岗位，以及缓慢积累起来的职级。这在底层领域不发生剧烈变化时是合理的。但现在，脚下的地面正在以同样的速度从所有人脚下移动。一个 22 岁、公开发布 agent demo 的年轻人，和一个 35 岁的资深工程师之间的差距，不再只是十年技术栈熟练度的积累。这个 22 岁的人和资深工程师面对的是同一张空白画布。对他们来说，真正会复利增长的是持续交付的意愿，以及那一小部分不会在一个季度内过时的基础能力。

这就是整篇文章的核心重构。接下来，我会提供一种判断方式：哪些基础能力值得你投入注意力，哪些发布可以直接让它过去。适合你的就拿走，不适合的就放下。

真正有效的过滤器

你不可能跟上每周的新发布，也不应该这么做。你需要的不是信息流，而是过滤器。

过去 18 个月里，有五个测试一直有效。在让某个新东西进入你的技术栈之前，先用这五个问题过一遍。

两年后它还重要吗？
如果它只是某个前沿模型外面套的一层壳、一个 CLI 参数，或者「某某版 Devin」，答案几乎总是否定的。如果它是一个基础原语，比如协议、记忆模式、沙盒方法，答案就更可能是肯定的。套壳产品的半衰期很短，基础原语的半衰期可以按年计算。

有没有你尊重的人，已经基于它做出了真实产品，并且诚实写过经验？
营销文章不算，复盘文章才算。一篇题为「我们在生产环境里试了 X，结果这里出问题了」的博客，比十篇发布公告更有价值。这个领域里真正有用的信号，永远来自那些为此失去过一个周末的人。

采用它，是否意味着你要丢掉现有的 tracing、重试机制、配置、认证系统？
如果是，那它就是一个试图把自己做成平台的框架。试图成为平台的框架，死亡率大约有 90%。好的基础原语，应该能嵌入你现有系统，而不是逼你迁移。

如果你跳过它六个月，代价是什么？
对大多数发布来说，答案是什么都没有。六个月后你会知道更多，胜出的版本也会更清楚。这一条测试，可以让你毫无焦虑地跳过 90% 的发布。但也是最多人拒绝使用的一条，因为跳过某个东西会让人感觉自己落后了。实际上并不是。

你能否衡量它是否真的让你的 agent 变好了？
如果不能，那你只是在猜。没有 eval 的团队靠感觉运行，最终会把回归问题发到线上。有 eval 的团队，则可以让数据告诉自己：在本周这个具体工作负载上，到底是 GPT-5.5 更好，还是 Opus 4.7 更好。

如果你只从这篇文章里带走一个习惯，那就是：每当一个新东西发布时，写下你需要在六个月后看到什么，才会相信它真的重要。然后六个月后回来检查。大多数时候，问题自己已经给出了答案，而你的注意力也会被用在那些真正能复利增长的事情上。

这些测试背后真正的能力，比任何一条测试都更难命名。它是一种愿意「不赶时髦」的能力。这个星期在 Hacker News 爆火的框架，会在十四天内拥有一支啦啦队，他们听起来都会很聪明。但六个月后，其中一半框架已经无人维护，那些啦啦队也早已转向下一个热点。没有参与其中的人，把注意力省下来，留给那些在发布热潮过去后依然经受住「变得无聊」考验的东西。克制、观望、说一句「六个月后我就知道了」，才是这个领域真正的职业技能。所有人都会读发布公告，但几乎没人擅长不对它们做反应。

该学什么

概念、模式、事物的形状。真正带来复利回报的是这些东西。它们能穿越模型替换、框架替换和范式转移。深刻理解它们，你就能在一个周末内上手任何新工具。跳过它们，你就会永远在重新学习表层机制。

Context Engineering

过去两年里，最重要的一次改名，是「Prompt Engineering」变成了「Context Engineering」。这个变化是真的，不只是换个说法。

模型不再是一个你给它写一条聪明指令的东西。它变成了一个你需要在每一步为其组装可工作上下文的东西。这个上下文同时包含系统指令、工具 schema、检索到的文档、之前的工具输出、scratchpad 状态，以及压缩后的历史记录。Agent 的行为，是你放进上下文窗口里的所有内容共同涌现出来的结果。

你需要内化这一点：上下文就是状态。每一个无关 token 都会消耗推理质量。上下文腐烂，是一种真实的生产故障。到一个十步任务的第八步时，最初目标可能已经被工具输出埋掉了。能交付可靠 agent 的团队，会主动总结、压缩、裁剪上下文。他们会给工具描述做版本管理，会缓存静态部分，也会拒绝缓存会变化的部分。他们看待上下文窗口的方式，就像一个有经验的工程师看待内存。

一个具体的感受方式是：拿任意一个生产环境里的 agent，打开完整 trace 日志。看看第一步时的上下文，再看看第七步时的上下文。数一数还有多少 token 仍然在发挥作用。第一次做这件事时，你大概率会感到尴尬。然后你会去修它，而同一个 agent 会在不更换模型、不改 prompt 的情况下，明显变得更可靠。

如果你只读一篇相关内容，就读 Anthropic 的《Effective Context Engineering for AI Agents》。然后再读他们关于多 agent 研究系统的复盘，那篇文章用数字说明了当系统规模扩大后，上下文隔离有多重要。

工具设计

工具是 agent 与你的业务发生接触的地方。模型会根据工具名称和描述来选择工具，会根据错误信息来决定如何重试。工具的契约是否符合 LLM 擅长表达的方式，决定了模型是成功还是失败。

五到十个命名良好的工具，胜过二十个平庸的工具。工具名称应该像自然英文里的动词短语。描述应该写清楚什么时候该用，什么时候不该用。错误信息应该是模型可以据此行动的反馈。「超过 500 个 token 上限，请先总结再尝试」远胜于「Error: 400 Bad Request」。公开研究中有一个团队报告称，他们仅仅重写错误信息，就让重试循环减少了 40%。

Anthropic 的《Writing tools for agents》是很好的起点。读完之后，给你自己的工具加上观测，看看真实调用模式。Agent 可靠性最大的提升，几乎总是发生在工具侧。很多人不断调 prompt，却忽视了真正杠杆所在的位置。

Orchestrator-Subagent 模式

2024 年和 2025 年关于多 agent 的争论，最终收敛成了一个如今大家都在采用的综合方案。天真的多 agent 系统，也就是多个 agent 并行写入共享状态的系统，会灾难性失败，因为错误会不断复合。单 agent 循环能扩展到的程度，往往比你想象中更远。真正能在生产环境里工作的多 agent 形态只有一种：一个 orchestrator agent，把范围狭窄、只读的任务委派给隔离的 subagent，然后再综合它们的结果。

Anthropic 的研究系统是这样工作的。Claude Code 的 subagents 也是这样工作的。Spring AI 和多数生产框架现在也在标准化这一模式。Subagent 拥有小而聚焦的上下文，不能修改共享状态。写入由 orchestrator 负责。

Cognition 的《Don』t Build Multi-Agents》和 Anthropic 的《How we built our multi-agent research system》看起来像是相反观点，但其实只是用不同词汇在说同一件事。两篇都值得读。

默认使用单 agent。只有当单 agent 确实撞到真实边界时，再考虑 orchestrator-subagent：比如上下文窗口压力、顺序工具调用带来的延迟，或者任务异质性确实能从聚焦上下文中获益。在还没有感受到痛点之前就构建这套东西，只会交付你并不需要的复杂性。

Evals 与黄金数据集

每一个能交付可靠 agent 的团队都有 eval。没有 eval 的团队，通常也交付不出可靠 agent。这是这个领域杠杆最高的习惯，也是我在每家公司里看到的最被低估的事情。

有效做法是：收集生产环境 trace，标注失败案例，把它们当作回归集。每当新的失败上线，就把它加进去。主观部分使用 LLM-as-judge，其他部分使用精确匹配或程序化检查。在任何 prompt、模型或工具变更之前，都跑一遍测试套件。Spotify 工程博客报告称，他们的 judge 层会在输出上线前拦下大约 25% 的 agent 输出。如果没有它，每四个坏结果中就会有一个抵达用户面前。

让这件事真正扎根的心智模型是：eval 就是一个单元测试，用来在其他所有东西都不断变化时，确保 agent 没有偏离职责。模型会出新版本，框架会发布破坏性变更，供应商会废弃某个端点。你的 eval 是唯一能告诉你 agent 是否还在正常工作的东西。没有 eval，你就在写一个正确性取决于移动目标善意的系统。

Eval 框架，比如 Braintrust、Langfuse evals、LangSmith，都还不错。但它们都不是瓶颈。真正的瓶颈，是你首先有没有一个已标注的数据集。第一天就该开始做，在扩展任何东西之前就做。最初的 50 个样本，一个下午就能手工标完。没有借口。

把文件系统当作状态，以及 Think-Act-Observe 循环

对于任何执行真实多步骤工作的 agent 来说，耐用的架构都是：思考、行动、观察、重复。文件系统或结构化存储，是事实来源。每个动作都被记录，并且可以重放。Claude Code、Cursor、Devin、Aider、OpenHands、goose 都收敛到这一点，不是没有原因的。

模型本身是无状态的。运行框架必须是有状态的。文件系统是每个开发者都已经理解的有状态基础原语。一旦接受这个框架，整套 harness 纪律都会自然展开：checkpoint、可恢复性、sub-agent 验证、沙盒执行。

这里更深的一层启发是：在任何值得为其支付算力账单的生产 agent 中，harness 做的工作都比模型更多。模型选择下一步行动，harness 验证它，在沙盒中运行它，捕获输出，决定把什么反馈回去，决定什么时候停止，决定什么时候 checkpoint，决定什么时候生成 subagent。把模型换成另一个同等质量的模型，一个好的 harness 仍然能交付产品。把 harness 换成一个更差的，即使是世界上最好的模型，也会产出一个会随机忘记自己在做什么的 agent。

如果你构建的东西比一次性工具调用更复杂，那么你真正应该投入时间的地方是 harness。模型只是其中的一个组件。

从概念上理解 MCP

不要只是学习怎么调用 MCP server。要学习它的模型。它在 agent 能力、工具与资源之间建立了清晰分离，并在底层提供了可扩展的认证与传输方案。一旦理解了这一点，你看到的其他「agent 集成框架」，都会像是 MCP 的低配版，你也就省下了逐个评估它们的时间。

Linux Foundation 现在负责托管 MCP。所有主要模型提供商都支持它。把它比作「AI 的 USB-C」，现在已经比讽刺更接近事实。

沙盒化是一种基础原语

每一个生产级 coding agent 都运行在沙盒里。每一个浏览器 agent 都遭遇过间接 prompt injection。每一个多租户 agent，某个阶段都出现过权限范围 bug。你应该把沙盒化当作基础设施原语，而不是等客户提出要求后才添加的功能。

要学基础知识：进程隔离、网络出口控制、密钥范围管理、agent 与工具之间的认证边界。那些等客户安全审查后才临时补上的团队，往往会丢掉交易。那些从第一周就把它做进去的团队，才会在企业采购流程中轻松通过。

该用什么构建

以下是截至 2026 年 4 月的具体选择。这些选择会变化，但不会变化得太快。在这一层，尽量选「无聊但稳」的东西。

编排层

LangGraph 是生产环境里的默认选择。大约三分之一运行 agent 的大型公司都在用它。它的抽象方式符合 agent 系统的真实形态：类型化状态、条件边、持久化工作流，以及 human-in-the-loop 检查点。缺点是写起来啰嗦；优点是，当一个 agent 真正进入生产环境后，你确实需要控制这些东西，而它的啰嗦正好对应了这些控制需求。

如果你主要使用 TypeScript，Mastra 是事实上的选择。它是这个生态里心智模型最清晰的方案。

如果你的团队喜欢 Pydantic，并且希望把类型安全作为一等公民，Pydantic AI 是一个合理的 greenfield 选择。它在 2025 年底发布了 v1.0，势头确实存在。

如果是 provider-native 的工作，比如 computer use、语音、实时交互，可以在 LangGraph 节点里使用 Claude Agent SDK 或 OpenAI Agents SDK。不要试图让它们成为异构系统的顶层编排器。它们是为各自擅长的场景优化的。

协议层

MCP，没别的。

把你的工具集成做成 MCP server。外部集成也用同样方式消费。现在 MCP registry 已经越过了临界点：大多数情况下，在你需要自己构建之前，已经能找到一个现成 server。2026 年还在手写自定义工具 plumbing，基本是在白交税。

记忆层

选择记忆系统时，不要按热度选，要按 agent 的自主程度选。

Mem0 适合聊天式个性化：用户偏好、轻量历史记录。Zep 适合生产级对话系统，尤其是状态会持续演化、需要实体追踪的场景。Letta 适合那些需要在几天甚至几周工作周期里保持一致性的 agent。大多数团队不需要这个；但真正需要的团队，需要的正是它。

常见错误是：还没有记忆问题，就先上记忆框架。先从上下文窗口能容纳的内容，加一个向量数据库开始。只有当你能清楚说出它要解决的失败模式时，再加入记忆系统。

可观测性与 evals

Langfuse 是开源默认选择。它可以自托管，采用 MIT 许可证，覆盖 tracing、prompt 版本管理，以及基础的 LLM-as-judge evals。如果你已经是 LangChain 用户，LangSmith 集成会更紧密。Braintrust 适合研究型 eval 工作流，尤其是需要严谨比较的场景。OpenLLMetry / Traceloop 则适合需要 vendor-neutral OpenTelemetry instrumentation 的多语言技术栈。

你需要同时拥有 tracing 和 evals。Tracing 回答的是：「agent 到底做了什么？」Evals 回答的是：「agent 比昨天变好了，还是变差了？」没有这两样，不要上线。第一天就把这些东西接好，成本远低于在盲跑之后再补救。

运行时与沙盒

E2B 适合通用的沙盒代码执行。Browserbase 搭配 Stagehand，适合浏览器自动化。Anthropic Computer Use 适合需要真实操作系统级桌面控制的场景。Modal 适合短时突发任务。

永远不要运行未沙盒化的代码执行。一个被 prompt injection 攻破的 agent，如果直接在生产环境中运行，其爆炸半径会变成一个你绝不想讲给别人听的故事。

模型

追 benchmark 很累，而且大多数时候没太大帮助。务实地看，截至 2026 年 4 月：

·Claude Opus 4.7 和 Sonnet 4.6 适合可靠的工具调用、多步骤一致性，以及优雅的失败恢复。对大多数工作负载·来说，Sonnet 是成本与性能之间的甜点位。

·GPT-5.4 和 GPT-5.5 适合需要最强 CLI / terminal 推理能力，或者你本身就生活在 OpenAI 基础设施里的场景。

·Gemini 2.5 和 3 适合长上下文密集型，或者多模态密集型任务。

·当成本比顶级性能更重要时，尤其是处理边界清晰、定义狭窄的任务，可以考虑 DeepSeek-V3.2 或 Qwen 3.6。

把模型视为可替换组件。如果你的 agent 只能在某一个模型上工作，这不是护城河，而是坏味道。用 evals 决定部署什么模型。每个季度重新评估一次，不要每周都追着换。

什么可以跳过

你会不断被人劝去学习、使用下面这些东西。其实不需要。跳过它们的代价很低，省下的时间很多。

AutoGen 和 AG2，不要用于生产。
Microsoft 的这个框架已经转向社区维护，发布节奏停滞，抽象方式也不符合生产团队真正需要的形态。做学术探索可以，但不要把产品押在上面。

CrewAI，不要用于新的生产构建。
它到处都能看到，因为它很适合做 demo。真正构建生产系统的工程师已经在迁出它。你想用它做原型可以，但不要长期绑定。

Microsoft Semantic Kernel，除非你已经深度锁定在 Microsoft 企业技术栈里，而且你的买方也在意这一点。
它不是生态系统正在走向的方向。

DSPy，除非你专门在大规模优化 prompt programs。
它有哲学价值，但受众很窄。它不是通用 agent 框架，也不要把它当成通用框架来选。

把独立 code-writing agent 当作架构选择。
Code-as-action 是有意思的研究方向，但它还不是生产环境里的默认模式。你会遇到许多工具链和安全问题，而你的竞争对手可能根本不用处理这些。

「Autonomous agent」式推销。
AutoGPT 和 BabyAGI 那条产品形态上的路线已经死了。行业最终接受的诚实说法是「agentic engineering」：有监督、有边界、有评估。2026 年还在卖「部署后就不用管」的 autonomous agent 的人，本质上是在卖 2023 年的东西。

Agent app store 和 marketplace。
从 2023 年开始就有人承诺这件事，但从未真正获得企业 traction。企业不会购买通用的预制 agent。它们要么买和具体结果绑定的垂直 agent，要么自己构建。不要围绕一个 app store 梦想来设计你的业务。

作为客户，谨慎选择横向的「build any agent」企业平台。
例如 Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio 这一层。它们以后可能会有用，但现在仍然混乱、发版慢，而且 buy-versus-build 的账通常仍然倾向于：自己构建一个窄 agent，或者购买一个垂直 agent。Salesforce Agentforce 和 ServiceNow Now Assist 是例外，因为它们赢在已经嵌入你正在使用的工作流系统里。

不要追 SWE-bench 和 OSWorld 排行榜。
Berkeley 研究人员在 2025 年记录到，几乎所有公开 benchmark 都可以被刷榜，而不需要真正解决底层任务。现在团队会把 Terminal-Bench 2.0 和自己的内部 evals 当作更真实的信号。默认对单一数字的 benchmark 飞跃保持怀疑。

天真的并行多 agent 架构。
五个 agent 围绕共享记忆聊天，在 demo 里看起来很厉害，到了生产环境就会散架。如果你不能在餐巾纸上画出一张清晰的 orchestrator-subagent 图，并标明读写边界，就不要上线。

新 agent 产品不要用 per-seat SaaS 定价。
市场已经转向 outcome-based 和 usage-based。按席位收费不仅会让你少赚，还会向买方释放一个信号：你自己都不相信产品能交付结果。

这个星期你在 Hacker News 上看到的下一个框架。
等六个月。如果它到时候还重要，你会很清楚。如果它不重要，你就省下了一次迁移。

具体该怎么推进

如果你不是只想「跟上 agent」，而是真的想采用 agent，下面这个顺序是有效的。它很无聊，但有用。

先选一个已经重要的结果。不要选 moonshot，不要一上来做一个横向的「agent platform」项目。选一个你的业务本来就关心、而且可以衡量的事情：减少客服工单、生成第一版法律审查意见、筛选 inbound leads、生成月度报告。Agent 是否成功，取决于这个结果是否改善。它从第一天起就是你的 eval target。

这一步之所以比其他任何步骤都重要，是因为它会约束后续所有决策。有了具体结果，「选哪个框架」就不再是哲学问题，你会选择最快能交付这个结果的框架。「选哪个模型」也不再是 benchmark 争论，而是选择你的 evals 证明在这项具体工作上有效的模型。「我们需不需要记忆、subagents、定制 harness」也不再是思维实验，而是只在具体失败模式需要时才添加。

跳过这一步的团队，最后往往会做出一个没人要的横向平台。认真对待这一步的团队，通常会交付一个狭窄但能在一个季度内回本的 agent。而这个真正上线的 agent，会教会他们比读两年文章更多的东西。

在上线任何东西之前，先设置 tracing 和 evals。选 Langfuse 或 LangSmith，把它接好。必要时手工构建一个小型 golden dataset。50 个标注样本就足够开始。你无法改进自己无法衡量的东西。以后再补这套系统，成本大约是现在就做的 10 倍。

从一个单 agent 循环开始。选择 LangGraph 或 Pydantic AI。模型选择 Claude Sonnet 4.6 或 GPT-5。给 agent 三到七个设计良好的工具。让它用文件系统或数据库作为状态。先发给小范围用户，观察 traces。

把 agent 当作产品，而不是项目。它会以你没预料到的方式失败，而这些失败就是你的路线图。用真实生产 trace 构建 regression set。每一次 prompt 变更、模型替换、工具修改，都要在部署前通过 evals。大多数团队都低估了这里的投入，而大多数可靠性也正是从这里来的。

只有当你已经「挣到了」扩展范围的资格，再增加复杂度。上下文成为瓶颈时，再引入 subagents。单窗口上下文无法承载所需内容时，再引入记忆框架。底层 API 真不存在时，再引入 computer use 或 browser use。不要提前设计这些东西。让失败模式把它们拉进来。

选择无聊的基础设施。工具用 MCP。沙盒用 E2B 或 Browserbase。状态用 Postgres，或者你们已经在运行的数据存储。认证和可观测性也尽量沿用现有系统。奇特的基础设施很少是真正的胜负手，真正的胜负手是纪律。

从第一天就盯住单位经济模型。每次 action 成本、缓存命中率、重试循环成本、模型调用分布。Agent 在 PoC 阶段看起来很便宜，但如果你一开始没有按 outcome 监控成本，规模扩大 100 倍时成本会爆炸。一个 0.50 美元一次运行的 PoC，在中等规模下就可能变成每月 5 万美元。没提前看到这一点的团队，会迎来一场他们并不喜欢的 CFO 会议。

每个季度重新评估模型，而不是每周重新评估。锁定一个季度。季度结束时，用你的 eval suite 跑一遍当前前沿模型。如果数据说明该换，就换。这样你能获得模型进步的收益，同时避免追逐每次发布带来的混乱。

如何判断潮流

下面是一些具体信号，说明某件事可能是真的 signal：一个受尊重的工程团队写了带数字的 postmortem，而不只是宣称有多少人采用；它是一个基础原语，比如协议、模式或基础设施，而不是套壳或打包；它能和你已经运行的系统互操作，而不是替代它；它的 pitch 讲的是它解决了什么失败模式，而不是它开启了什么能力；它已经存在了足够长时间，长到有人能写出一篇「哪些地方没奏效」的博客。

下面是一些具体信号，说明某件事可能只是噪音：发布 30 天后仍然只有 demo 视频，没有生产案例；benchmark 跃升干净得不像真的；pitch 里不加限定地使用「autonomous」「agent OS」或「build any agent」；框架文档默认你会扔掉现有的 tracing、auth 和 config；star 数增长很快，但 commits、releases 和 contributors 没有同步增长；Twitter 速度很快，但 GitHub 速度跟不上。

一个有用的每周习惯是：周五留出 30 分钟看这个领域。读三样东西：Anthropic 工程博客、Simon Willison 的笔记、Latent Space。如果这一周有 postmortem，再扫一两篇。其他都可以跳过。真正重要的东西，你不会错过。

接下来值得观察什么

未来两个季度值得关注的事情，不是因为它们一定会赢，而是因为「这到底是不是 signal」这个问题还没有完全解决。

Replit Agent 4 的 parallel forking 模型。
这是第一批认真尝试「多个 agent 并行工作」但又不被共享状态绊倒的方案之一。如果它能在规模化后站住脚，orchestrator-subagent 这个默认模式可能会发生变化。

Outcome-based pricing 的成熟度。
Sierra 和 Harvey 的收入轨迹，已经在狭窄垂直领域验证了这一模式。问题是，它是否能推广到其他领域，还是只适用于垂直场景。

Skills 作为能力封装层。
GitHub 上 AGENTS.md 和 skills directories 的增多，说明一种封装 agent 能力的新方式正在出现。它是否会像 MCP 标准化工具那样标准化能力层，这是一个开放问题。

Claude Code 2026 年 4 月质量回退及其复盘。
一个行业领先的 agent 发布了一个造成 47% 性能回退的版本，而且是用户先发现，内部监控后发现。这说明即使在领先者那里，生产级 agent eval 实践仍然很不成熟。如果这件事推动整个行业投资更好的 online evals，那么这次纠偏是健康的。

语音成为默认客服界面。
Sierra 的语音渠道在 2025 年底已经超过文本渠道。如果这一模式在其他垂直领域延续，那么延迟、打断、实时工具调用等设计约束会变成一阶问题，很多现有架构都需要重做。

开源模型 agent 能力继续缩小差距。
DeepSeek-V3.2 原生支持 thinking-into-tool-use，Qwen 3.6 以及更广泛的开源模型生态都值得关注。狭窄 agent 任务上的成本性能比正在变化。闭源模型默认占优的局面不会永久存在。

这些事情中的每一件，都可以对应一个清晰问题：「六个月后，我需要看到什么，才会相信它真的重要？」这就是测试。追踪答案，而不是追踪公告。

反常识的赌注

每一个你没有采用的框架，都是一次你不欠未来的迁移。每一个你没有追逐的 benchmark，都是一个季度的专注力。这个周期里正在赢的公司——Sierra、Harvey、Cursor，各自在自己的领域中——都选择了狭窄目标，建立了无聊的纪律，然后让这个领域的噪音从身边经过。

传统路径是：选一个技术栈，花很多年掌握它，然后沿着阶梯往上爬。这在技术栈能稳定十年的时候是有效的。但现在，技术栈每个季度都在变。真正赢的人，不再优化「掌握某个技术栈」的能力，而是在优化品味、基础原语和交付速度。他们公开构建小东西，通过交付来学习。别人是因为他们已经做出来的东西，而把他们拉进房间。作品本身就是资历。

请认真想一想这一点，因为这正是整篇文章真正想说的。我们大多数人接受的工作模型，都假定这个世界会稳定足够久，让资历能够复利增长。你去上学，拿学位，爬梯子。这里待两年，那里待三年，简历慢慢变成能打开门的东西。整个机器的前提，是它对面的行业足够稳定。

但 agent 领域现在没有一个稳定的「对面」。你想加入的公司可能只有六个月大。它们构建所用的框架可能只有十八个月历史。底层协议可能也只有两年。这个领域里一半最常被引用的文章，作者三年前甚至还不在这个领域里。没有梯子可爬，因为这栋楼一直在变楼层。当梯子失效时，剩下的是一种更古老的方法：做出一个东西，放到互联网上，让作品替你介绍自己。这是一条反常识路径，因为它绕开了资历认证系统。但在一个不断移动的领域里，它也是唯一真正能复利增长的路径。

这就是从内部看到的时代样貌。连巨头也在公开迭代，发布回归问题，写复盘，在线修补。今年交付最有意思东西的团队里，有些人 18 个月前还不在这个领域。不会写代码的人正在和 agent 搭档，交付真实软件。博士可能会被那些选对基础原语并开始快速出手的构建者超越。大门已经打开。大多数人却还在找申请表。

你现在真正需要培养的技能，不是「agents」。而是在一个表层不断变化的领域里，判断哪些工作会复利增长的纪律。Context engineering 会复利增长。工具设计会复利增长。Orchestrator-subagent 模式会复利增长。Eval 纪律会复利增长。Harness 思维会复利增长。周二刚发布的框架 API 不会。一旦你能区分它们，每周一波又一波的新发布就不再像压力，而会变成你可以忽略的噪音。

你不需要学会所有东西。你需要学会那些会复利增长的东西，并跳过那些不会复利增长的东西。选一个 outcome。在上线前接好 tracing 和 evals。使用 LangGraph，或者你团队里的等价工具。使用 MCP。把 runtime 放进沙盒。默认从单 agent 开始。只有当失败模式把复杂度拉进来时，再扩大范围。每个季度重新评估模型。周五读三样东西。

这就是 playbook。剩下的，是品味、交付速度，以及不追逐无关紧要之物的耐心。

去构建东西。把它们放到互联网上。这个时代奖励的是做出东西的人，而不是只会描述东西的人。现在是成为那个「真正做出来的人」的最好窗口。