每天都有新框架、新 benchmark、新"10x 突破"。在 AI Agent 这个领域，真正的难题不再是"如何跟上"，而是"什么是信号，什么是噪声"。
作者在 AI 领域深耕两年，拿过 $250k+ 的 offer，目前在一家 stealth 公司做技术负责人。这篇文章是写给所有问"我现在到底该关注什么"的人。
第一个重构：证书 vs. 复利
传统路径优化的是证书：学位 → 初级岗位 → 高级岗位 → staff，漫长的晋升积累。但这个逻辑的前提是"你脚下的领域不动"。
AI 领域现在对所有人都在同等程度地动。22 岁用 Agent 在公开渠道发 demo 的人和 35 岁的资深工程师，差距不再是"十年的技术栈积累"。两者面对的是同一张白纸，真正复利的是：意愿去交付 + 少数不过时的基础能力。
五个过滤测试
作者在 18 个月里提炼出五个测试，任何新发布扔进去过一遍再做决定：
1. 两年后它还重要吗？ 如果是"某个前沿模型的包装"、一个"CLI flag"、或者"Devin + X"，答案通常是否。如果是协议、记忆模式、沙箱方案这类基础原语，答案更可能是肯定。包装类的半衰期很短，基础原语的半衰期以年计。
2. 你信任的人有没有在上面做过真东西并诚实复盘？ 营销稿不算。postmortem（复盘）才算。一篇"我们在线上用了 X，以下是踩坑记录"比十个发布公告都有价值。
3. 引入它需要推翻你现有的 tracing、retry、配置、认证体系吗？ 如果是，那它是一个试图成为平台的技术框架。技术框架试图成为平台，死亡率 90%。好的基础原语可以插入现有系统，不需要迁移。
4. 跳过六个月成本是什么？ 对大多数发布，答案是零。六个月后你会知道更多，赢家也会更清晰。这个测试能让你不带焦虑地跳过 90% 的发布——大多数人拒绝这样做是因为跳过感觉像落后，其实不是。
5. 你能衡量它是否真的帮到了你的 Agent 吗？ 如果不能，你就是在猜。没有评测的团队靠直觉跑，交付的是回归。
五个不过时的基础能力
上下文工程（Context Engineering）
过去两年最重要的重命名是"prompt engineering"变成了"context engineering"，这个转变是真实的，不是噱头。
模型不再是"你精心撰写指令"的对象，而是"你在每一步为之组装工作上下文"的对象。这个上下文包含：系统指令、工具 schema、检索文档、先前的工具输出、草稿状态、压缩后的历史。Agent 的行为是"你在窗口里放什么"的涌现属性。
核心认知：上下文就是状态。 每一点无关的 token 都在消耗推理质量。上下文腐烂是真实的生产故障。到了十步任务的第八步，最初的目标可能已经埋在了工具输出下面。真正交付可靠 Agent 的团队会主动总结、压缩、修剪。
一个具体的感受方法：打开完整的 trace 日志，看第一步的上下文，看第七步的上下文，数一数还有多少 token 仍在产生价值。第一次做这件事你会尴尬，然后你会去修复——同个 Agent 会明显变得更可靠，而不需要换模型或改 prompt。
工具设计
工具是 Agent 遇见业务的地方。模型根据名称和描述选择工具，根据错误消息重试，根据工具契约是否匹配 LLM 擅长表达的内容而成功或失败。
五到十个命名清晰的工具优于二十个平庸的工具。 工具名称要读起来像英文动词短语。描述要说明何时使用、何时不该用。错误消息要给出模型可操作的反馈。"Max tokens 500 exceeded, try summarizing first" 比"Error: 400 Bad Request" 好用太多。有团队报告，仅重写错误消息就减少了 40% 的重试循环。
核心杠杆在工具侧，人们却一直在调 prompt。
编排器-子 Agent 模式
2024-2025 年的多 Agent 辩论最终走向了一个所有人现在都在用的综合方案：naive 多 Agent 系统（在共享状态上并行写）会灾难性地失败，因为错误会叠加；单一 Agent 循环比你想的能延伸更远；唯一在生产环境中可行的多 Agent 形态是：一个编排器 Agent 向孤立的子 Agent 委托狭义只读任务，再综合结果。
Anthropic 的研究系统是这个模式，Claude Code 的子 Agent 也是，Spring AI 和大多数生产框架现在都在标准化这个模式。子 Agent 得到的是小型专注的上下文，不能修改共享状态，编排器拥有写权限。
先默认选单一 Agent。只有在单一 Agent 真正碰到瓶颈时才引入：上下文窗口压力、顺序工具调用的延迟、或任务异质性确实从专注上下文中受益。在此之前构建这个架构，只是交付了你不需要的复杂度。
评测和黄金数据集
交付可靠 Agent 的团队都有评测。没有评测的团队，没有评测。这是该领域复利最高的习惯，也是每家公司都投资不足的地方。
有效的做法：收获你的生产 traces，标注失败用例，把它作为回归集。每次新失败发生时往里加。用 LLM-as-judge 处理主观部分，精确匹配或程序化检查处理其余。在任何 prompt、模型或工具变更前跑这套测试。Spotify 工程团队报告，judge 层在他们交付前否决了约 25% 的 Agent 输出——没有它，四分之一的坏结果会触达用户。
心理模型：评测是单元测试，在其他一切都在变的时候保持 Agent 诚实。 模型新版发布、框架发布破坏性变更、供应商废弃端点，你的评测是唯一告诉你 Agent 是否还在做它该做的事的东西。
评测框架（Braintrust、Langfuse evals、LangSmith）都不错，都不是瓶颈。瓶颈是拥有一套标注集。第一天就建这个，再规模化。第一批五十个样本可以一下午手工标注完，没有借口。
MCP 的本质
不要只学怎么调用 MCP 服务器。要理解它的模型：Agent 能力、工具和资源的清晰分离，可扩展的认证和传输故事。理解了这个，你会把其他所有"Agent 集成框架"看成 MCP 的更差版本，省下评估每一个的时间。Linux 基金会现在在托管它，每个主要模型提供商都在支持它。"AI 的 USB-C"这个比喻现在比讽刺更准确。
沙箱隔离
每个生产级编码 Agent 都在沙箱里运行。每个浏览器 Agent 都被间接 prompt 注入击中过。每个多租户 Agent 都曾有过权限范围 bug。把沙箱隔离当作基础设具，而不是客户要求时再加的功能。学基础：进程隔离、网络出口控制、密钥范围、Agent 和工具之间的认证边界。在安全审查后再加这个的团队就是那个丢单的团队。从第一周就内置的团队不需要担心企业采购。
这篇文章的核心洞察不是什么新框架或新工具，而是一个认知框架：在 AI Agent 这个仍在形成的领域，真正的专业技能是"不对发布做出反应"的能力。每个人都能读发布公告。几乎没人擅长对它们不表态。那种"先等着，六个月后再看"的状态，才是这个领域的真正护城河。