编者按: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。剩下的,是品味、交付速度,以及不追逐无关紧要之物的耐心。

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