每天都会冒出一个新框架、一个新基准、一个新的“10 倍效率”发布。问题不再是“我要怎样才能跟上”。问题变成了：这里面到底什么是信号，什么只是披着紧迫感外衣的噪音。
每张路线图发布一个月后就会过时。你上个季度刚掌握的框架，现在已经成了遗产系统。你优化过的基准被刷爆、被替换。我们曾经被训练去走一条常规路径：有主题和层级的技术栈，有职位和年限的序列，缓慢爬升。AI 改写了这张画布。现在，只要有合适的提示词和足够好的品味，任何人都能交付过去需要一个有两年经验的工程师花一个 sprint 才能做完的工作。
专业能力仍然重要。没有什么能替代亲眼看过系统崩坏、凌晨两点调过内存泄漏、为了一个无聊但正确的选择和别人争论并最终被证明是对的经历。这种品味会复利增长。不再像过去那样复利增长的是：熟悉本周热门框架的 API 表面。六个月后它就会变。两年后真正赢的人，是早早选中了耐久的原语，然后让其余噪音从身边经过的人。
过去两年我一直在这个领域里构建东西，拿到过多个超过 25 万美元的 offer，现在在一家 stealth 公司负责技术。如果有人问我“眼下我到底应该关注什么”，我会把下面这些发给他。
这不是路线图。Agent 领域还没有目的地。大实验室正在公开迭代，把回归问题发布给数百万用户，写复盘，在线修补。如果 Claude Code 背后的团队都能发布一次 47% 的性能回归，而且要等用户社区发现之后才抓到，那么认为这一切背后存在一张稳定地图，本身就是幻想。所有人都还在摸索。创业公司正在繁荣，因为巨头们也同样不知道答案。不会写代码的人正在和 agent 结对，在周五交付周二时 ML 博士还认为不可能的软件。
这个时刻最有意思的地方，是它改变了“凭证”的意义。传统路径优化的是凭证：学历、初级岗位、高级岗位、Staff 岗位，职级的缓慢积累。当脚下的领域不移动时，这很合理。但现在，整个领域在所有人脚下同样移动。一个 22 岁、公开发布 agent demo 的人，和一个 35 岁的资深工程师之间，差距不再是十年技术栈熟练度的积累。22 岁的人拥有和资深工程师一样的空白画布。对他们二者来说，真正复利增长的是愿意交付，以及那一小组不会在一个季度后过时的原语。
这就是整篇文章的重构视角。接下来是一套思考方式：哪些原语值得你投入注意力，哪些发布可以放过去。挑适合你的。其余留下。
真正有用的过滤器
你不可能跟上每周的发布。也不应该尝试。你需要的是过滤器，不是信息流。
过去 18 个月里，有五个测试一直有效。让一个新发布通过这些测试，再允许它碰你的技术栈。
两年后它还重要吗？如果它只是前沿模型外面的一层包装、一个 CLI flag，或者“Devin but for X”，答案几乎总是否定的。如果它是一个原语（协议、记忆模式、沙箱方法），答案更可能是肯定的。包装器的半衰期很短。原语的半衰期以年计。
有没有你尊重的人在它上面构建过真实东西，并且诚实地写过经验？营销文章不算。复盘算。一篇叫“我们在生产环境试了 X，这是坏掉的地方”的博客，价值胜过十篇发布公告。这个领域里的好信号，永远来自那些为它损失过一个周末的人。
采用它是否要求你扔掉现有的 tracing、retry、config、auth？如果是，那它就是一个试图成为平台的框架。试图成为平台的框架有 90% 的死亡率。好的原语会嵌入你现有系统，而不是强迫你迁移。
跳过它六个月的代价是什么？对大多数发布来说，答案是什么也没有。六个月后你会知道更多。赢家版本会更清楚。这项测试能让你毫无焦虑地跳过 90% 的发布，也是大多数人拒绝执行的测试，因为跳过会让人感觉像落后。但并不是。
你能衡量它是否真的帮助了你的 agent 吗？如果不能，你就是在猜。没有 eval 的团队靠感觉运转，然后发布回归。有 eval 的团队可以让数据告诉他们，在本周自己的具体 workload 上，到底 GPT-5.5 还是 Opus 4.7 更好。
如果你只从整篇文章里带走一个习惯，就带走这个：每当有新东西发布，写下六个月后你需要看到什么，才会相信它重要。然后回来检查。大多数时候，问题会自己给出答案，而你的注意力也会花在真正会复利的事情上。
这些测试背后的能力，比任何单项测试都更难命名。它是愿意对自己不采用的东西显得“不酷”。这周在 Hacker News 爆红的框架，会有一支持续十四天的啦啦队，而且他们听起来都很聪明。六个月后，其中一半框架无人维护，啦啦队也转移阵地了。没有参与的人，把注意力省给了那些发布热潮过去后仍能经受“变得无聊”考验的东西。这种姿态——后退一步、观察、说“六个月后我会知道”——才是这个领域真正的专业能力。每个人都能阅读发布。几乎没人擅长不对发布做出反应。
该学什么
概念。模式。事物的形状。这些想法会带来复利回报。它们能穿过模型替换、框架替换和范式变化。深入理解它们，你可以在一个周末里上手任何新工具。跳过它们，你就会永远反复学习表层机制。
Context engineering
过去两年最重要的一次重命名，是“prompt engineering”变成了“context engineering”。这个转变是真的，不是修辞。
模型不再是你为它精心写一条聪明指令的东西。它变成了你在每一步为它组装可工作上下文的东西。这个上下文同时包括 system instructions、tool schemas、检索到的文档、之前的工具输出、scratchpad 状态和压缩后的历史。Agent 的行为，是你放进窗口里的东西涌现出的属性。
请内化这一点：上下文就是状态。每个无关噪音 token 都会消耗推理质量。上下文腐烂是真实的生产故障。一个十步任务到第八步时，原始目标可能已经被工具输出埋没。能交付可靠 agent 的团队，会主动总结、压缩、剪枝。他们给工具描述做版本管理。他们缓存静态部分，拒绝缓存变化部分。他们思考上下文窗口的方式，就像有经验的工程师思考 RAM。
一个具体感受它的方法：拿任意一个生产中的 agent，打开完整 trace logging。看第一步的上下文。再看第七步的上下文。数一数里面还有多少 token 仍然物有所值。第一次做这件事时，你会尴尬。然后你会去修它，而同一个 agent 会明显更可靠，不需要改模型，也不需要改提示词。
如果你只读一篇相关内容，读 Anthropic 的《Effective Context Engineering for AI Agents》。然后读他们的多 agent 研究复盘，里面用数字说明了当系统扩展后，上下文隔离有多重要。
工具设计
工具是 agent 接触你业务的地方。模型根据名称和描述选择工具。模型根据错误消息重试。模型成功还是失败，取决于工具契约是否匹配 LLM 擅长表达的东西。
五到十个命名良好的工具，胜过二十个平庸工具。工具名应该读起来像英文动词短语。描述应该包含什么时候使用这个工具，以及什么时候不要使用。错误消息应该是模型可以据此行动的反馈。“Max tokens 500 exceeded, try summarizing first” 比 “Error: 400 Bad Request” 好太多。一个公开研究团队报告说，仅仅重写错误消息，就让 retry loop 降低了 40%。
Anthropic 的《Writing tools for agents》是正确的起点。之后，给你自己的工具加 instrumentation，查看实际调用模式。Agent 可靠性的最大收益几乎总是在工具侧。人们一直调提示词，却忽略了真正杠杆所在的地方。
Orchestrator-subagent 模式
2024 和 2025 年的多 agent 争论，最终收束到一个现在所有人都在交付的综合形态。天真的多 agent 系统——多个 agent 并行写入共享状态——会灾难性失败，因为错误会复合。单 agent loop 能扩展到比你想象中更远。生产里真正有效的多 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 和 golden datasets
每个能交付可靠 agent 的团队都有 eval。没有 eval 的团队，就没有可靠 agent。这是这个领域里杠杆最高的习惯，也是我在看过的每家公司里见到的投入最不足的东西。
有效做法是：收集生产 traces，标注失败，把它当成回归集。每次新失败上线，就把它加进去。主观部分用 LLM-as-judge，其余部分用 exact-match 或程序化检查。任何提示词、模型或工具变更前都跑一遍套件。Spotify 的工程博客报告说，他们的 judge 层在发布前拦截了约 25% 的 agent 输出。没有它，四分之一的坏结果就会到达用户。
让这个习惯站稳的心智模型是：eval 是一个单元测试，在底下一切都在变化时保持 agent 诚实。模型出了新版本。框架发布 breaking change。供应商弃用了 endpoint。你的 eval 是唯一能告诉你 agent 是否还在做它该做事情的东西。没有 eval，你写的系统，其正确性依赖于一个移动目标的善意。
Eval 框架（Braintrust、Langfuse evals、LangSmith）都还可以。它们都不是瓶颈。瓶颈是一开始就有一组标注数据。第一天就构建它，在扩张任何东西之前。最初 50 个样例可以一个下午手工标好。没有借口。
文件系统作为状态，以及 think-act-observe loop
对任何真正做多步工作的 agent 来说，耐久架构是：think、act、observe、repeat。文件系统或结构化存储作为事实来源。每个动作都记录下来，并且可重放。Claude Code、Cursor、Devin、Aider、OpenHands、goose。它们全都收敛到这里是有原因的。
模型是无状态的。Harness 必须是有状态的。文件系统是每个开发者都已经理解的有状态原语。一旦接受这个框架，整个 harness discipline——checkpointing、可恢复性、sub-agent 验证、沙箱执行——都会自然从认真对待这个模式中推导出来。
更深的一点是：在任何值得算力账单的生产 agent 里，harness 做的工作都比模型更多。模型选择下一个动作。Harness 验证它，在沙箱里运行它，捕获输出，决定把什么喂回去，决定什么时候停止，决定什么时候 checkpoint，决定什么时候生成 subagent。把模型换成另一个质量相近的模型，好的 harness 仍然能交付。把 harness 换成更差的，再好的模型也会产出一个随机忘记自己在做什么的 agent。
如果你在构建任何比单次工具调用更复杂的东西，harness 才是你应该投入时间的地方。模型只是其中一个组件。
MCP，概念层面
不要只学习如何调用 MCP server。要学习它的模型：agent 能力、工具和资源之间的清晰分离，底下有可扩展的 auth 和 transport 叙事。一旦理解它，你看到的每个其他“agent integration framework”都会像是 MCP 的劣化版本，而你会省下逐一评估它们的时间。
Linux Foundation 现在在托管它。每个主要模型提供商都支持它。“AI 的 USB-C”这个比喻现在更准确，已经不只是玩笑。
沙箱作为原语
每个生产编码 agent 都运行在沙箱里。每个浏览器 agent 都被间接提示注入打中过。每个多租户 agent 都在某个时候发布过权限范围 bug。把沙箱当成原语基础设施，而不是客户要求时才添加的功能。
学习基础知识。进程隔离。网络出口控制。Secret 作用域。Agent 和工具之间的 auth 边界。那些在客户安全审查后才补这些东西的团队，会丢掉交易。从第一周就内建这些东西的团队，能不出汗地通过企业采购。
该用什么构建
具体选择，2026 年 4 月。这些会变，但会慢慢变。这里要选无聊的东西。
Orchestration
LangGraph 是生产默认选择。大约三分之一运行 agent 的大公司在用它。它的抽象匹配 agent 系统的真实形状：typed state、conditional edges、durable workflows、human-in-the-loop checkpoints。缺点是啰嗦。优点是，一旦 agent 进入生产环境，这种啰嗦正好对应你真正需要控制的东西。
如果你生活在 TypeScript 里，Mastra 是那个生态里的事实选择。它的心智模型最干净。
如果你的团队喜欢 Pydantic，并且想把类型安全作为一等公民，Pydantic AI 是合理的 greenfield 选择。它在 2025 年末到达 v1.0，势头是真的。
对于 provider-native 工作（computer use、voice、real-time），在 LangGraph 节点里使用 Claude Agent SDK 或 OpenAI Agents SDK。不要试图把它们任何一个作为异构系统的顶层 orchestrator。它们是为自己的赛道优化的。
协议层
MCP，就这么简单。把你的工具集成构建成 MCP server。以同样方式消费外部集成。Registry 已经跨过了一个点：几乎总能先找到 server，再决定是否要自己构建。2026 年再手写自定义工具 plumbing，是在白交税。
Memory
按 autonomy level 选择，而不是按热度选择。
Mem0 用于 chat-style personalization：用户偏好、轻量历史。Zep 用于生产级对话系统，其中状态会演化，而且你需要 entity tracking。Letta 用于 agent 需要在数天或数周工作中保持连贯性的情况。大多数团队不需要这个。真正需要的团队，需要的正是这个。
错误在于还没有 memory problem 就先去拿 memory framework。先从上下文窗口能容纳的内容加一个 vector store 开始。只有当你能说清它解决的失败模式时，再添加 memory system。
Observability 和 evals
Langfuse 是 OSS 默认选择。可自托管，MIT 许可，覆盖 tracing、prompt versioning 和基本 LLM-as-judge evals。如果你已经是 LangChain shop，LangSmith 集成更紧密。Braintrust 适合需要严谨比较的研究型 eval 工作流。如果你需要 polyglot stack 里的 vendor-neutral OpenTelemetry instrumentation，答案是 OpenLLMetry / Traceloop。
你既需要 tracing，也需要 evals。Tracing 回答“agent 实际做了什么？”Evals 回答“agent 比昨天更好还是更差？”没有二者都别发布。盲飞的成本是第一天正确接入这些东西成本的十倍。
Runtime 和 sandbox
E2B 用于通用沙箱代码执行。Browserbase（配合 Stagehand）用于浏览器自动化。需要真正 OS 级桌面控制时用 Anthropic Computer Use。Modal 用于短生命周期 burst。不要运行非沙箱代码执行。永远不要。一个被提示注入的 agent 在生产环境里造成的爆炸半径，是你不会想讲的故事。
模型
追逐 benchmark 很累，而且大多没用。实际一点，在 2026 年 4 月：
Claude Opus 4.7 和 Sonnet 4.6 适合可靠工具使用、多步连贯性和优雅失败恢复。Sonnet 是大多数 workload 的成本性能甜点。需要最强 CLI/terminal 推理，或者你生活在 OpenAI infra 里时，用 GPT-5.4 和 5.5。长上下文重或多模态重的任务用 Gemini 2.5 和 3。成本比顶级性能更重要，尤其是狭窄且定义明确的任务，用 DeepSeek-V3.2 或 Qwen 3.6。
把模型当成可替换的。如果你的 agent 只能用一个模型工作，那是异味，不是护城河。用 evals 决定部署什么。每季度重新评估一次，不要每周重新评估。
该跳过什么
会有人告诉你这些都要学、都要用来构建。你不需要。跳过的成本很低。省下的时间很大。
AutoGen 和 AG2 用于生产。微软的框架转向社区维护，发布停滞，抽象不匹配生产团队真正需要的东西。学术探索可以。别把产品锚在上面。
CrewAI 用于新的生产构建。它无处不在，因为 demo 很容易。构建真实系统的工程师已经离开它了。想做原型可以用。不要承诺它。
Microsoft Semantic Kernel，除非你被锁在微软企业栈里，而且你的买家在乎你用了它。它不是生态正在前往的方向。
DSPy，除非你专门在大规模优化 prompt programs。它有哲学价值，但受众很窄。不是通用 agent framework。不要把它当成通用框架来选。
Standalone code-writing agents 作为你的架构选择。Code-as-action 是有意思的研究。它还不是生产默认模式，你会和 tooling 及安全问题搏斗，而你的竞争对手不用。
“Autonomous agent” 推销。AutoGPT 和 BabyAGI 那一脉在产品形态上已经死了。行业沉淀下来的诚实表述是“agentic engineering”：受监督、有边界、可评估。2026 年还在卖 deploy-and-forget autonomous agents 的人，卖的是 2023 年。
Agent app stores 和 marketplaces。自 2023 年起一直被承诺，但从未获得企业 traction。企业不买通用预构建 agent。它们买绑定结果的垂直 agent，或者自己构建。不要围绕 app-store 梦想设计你的业务。
横向“build any agent”企业平台作为客户选择（Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio tier）。它们最终会有用。现在它们混乱、发货慢，buy-versus-build 仍然更偏向自己构建窄 agent 或购买垂直 agent。Salesforce Agentforce 和 ServiceNow Now Assist 是例外，因为它们赢在嵌入你已经使用的 workflow system。
SWE-bench 和 OSWorld leaderboard chasing。Berkeley 研究人员在 2025 年持续记录到，几乎每个公开 benchmark 都可以在不解决底层任务的情况下被 game。团队现在把 Terminal-Bench 2.0 和自己的内部 eval 当成真实信号。默认怀疑单数字 benchmark 跃升。
天真的并行 multi-agent 架构。五个 agent 在共享内存上聊天，demo 里很震撼，生产里会崩。如果你不能在餐巾纸上画出一个有清晰读写边界的 orchestrator-subagent 图，就不要发布它。
新 agent 产品的 per-seat SaaS pricing。市场已经转向按结果和用量计价。按 seat 定价会把钱留在桌上，也向买家暗示你并不相信自己的产品能交付结果。
你这周在 Hacker News 上看到的下一个框架。等六个月。如果它仍然重要，会很明显。如果不重要，你省了一次迁移。
具体怎么行动
如果你想采用 agent，而不只是跟上它们，这个顺序有效。它很无聊。但它有效。
选一个已经重要的 outcome。不是 moonshot。不是一个横向“agent platform”项目。选某件可衡量、且你的业务已经在乎的事情。分流支持工单。起草第一版法律审查。筛选 inbound leads。生成月报。当这个 outcome 改善时，agent 就成功了。这会在第一天成为你的 eval target。
这一步之所以比任何事都重要，是因为它约束了后续每个决定。有了具体 outcome，“哪个框架”的问题就不再是哲学问题。你选能最快交付 outcome 的那个。“哪个模型”的问题也不再是 benchmark 争论。你选 evals 显示在这个具体工作上有效的那个。“我们是否需要 memory / subagents / custom harness”不再是思想实验。你只添加具体失败模式要求的东西。跳过这一步的团队，最后会构建没人要求的横向平台。认真执行这一步的团队，会交付一个窄 agent，让它在一个季度内为自己买单，而这个已交付的单一 agent，会比读两年文章更能教会他们这个领域。
在发布任何东西之前，先设置 tracing 和 evals。选 Langfuse 或 LangSmith。接上它。必要的话手工构建一个小 golden dataset。50 个标注样例足以开始。你无法改进无法衡量的东西。以后再补的成本，大约是现在补的 10 倍。
从一个单 agent loop 开始。选 LangGraph 或 Pydantic AI。模型选 Claude Sonnet 4.6 或 GPT-5。给 agent 三到七个设计良好的工具。给它文件系统或数据库作为状态。发布给小范围用户。观察 traces。
把 agent 当成产品，而不是项目。它会以你预料不到的方式失败。这些失败就是你的路线图。从真实生产 traces 构建回归集。每次提示词变更、模型替换、工具变更，在部署前都要经过 evals。大多数团队在这里投入不足。大多数可靠性也来自这里。
只有当你已经挣到资格时，再扩大 scope。上下文成为瓶颈时，引入 subagents。单窗口上下文无法容纳所需信息时，引入 memory frameworks。底层 API 确实不存在时，引入 computer use 或 browser use。不要预先架构这些。让失败模式把它们拉进来。
选择无聊的基础设施。工具用 MCP。沙箱用 E2B 或 Browserbase。状态用 Postgres，或者你们已经在运行的数据存储。Auth 和 observability 用你现有的栈。异国情调的 infra 很少是胜负手。纪律才是。
从第一天开始关注 unit economics。每次 action 成本。Cache hit rate。Retry-loop 成本。模型调用分布。Agent 在 PoC 里看起来很便宜，但如果你一开始不按 outcome instrument 成本，100 倍规模时会爆炸。一个 0.50 美元一次的 PoC，在中等流量下会变成每月 5 万美元。没提前看见的团队，会迎来一场他们不喜欢的 CFO 会议。
每季度重新评估模型，不要每周。锁定一个季度。季度末，用你的 eval suite 跑当前前沿模型；如果数据说该换，就换。这样你获得模型进步的收益，又不必承受追逐每次发布的混乱。
读懂潮水
某个东西是信号的具体迹象：
受尊重的工程团队写了带数字的复盘，而不是只有采用声明。它是原语（协议、模式、infra），不是 wrapper 或 bundle。它能和你已运行的东西互操作，而不是替换它。Pitch 描述的是它解决的失败模式，不是它启用的能力。它已经存在到足够久，久到有人写了“哪些地方没奏效”的博客。
某个东西是噪音的具体迹象：
发布 30 天后仍然只有 demo 视频，没有生产案例研究。Benchmark 跃升干净得不真实。Pitch 使用“autonomous”、“agent OS”或“build any agent”，但没有限定条件。框架文档假设你会扔掉现有 tracing、auth 和 config。Star 数快速上升，但 commits、releases 和 contributors 没有同步上升。Twitter velocity 很高，GitHub velocity 没跟上。
一个有用的每周习惯：周五留 30 分钟给这个领域。读三样东西。Anthropic 的工程博客。Simon Willison 的笔记。Latent Space。如果有复盘发布，扫一两篇。跳过这周其余所有东西。你会知道真正重要的事。
值得观察什么
接下来两个季度值得关注的东西，不是因为它们一定会赢，而是因为“这是不是信号？”的问题还没有完全解决：
Replit Agent 4 的 parallel forking model。第一次严肃尝试“多个 agent 并行工作”且不被共享状态绊倒。如果它在规模上站得住，orchestrator-subagent 默认模式可能会移动。
Outcome-based pricing 的成熟度。Sierra 和 Harvey 的收入轨迹，在窄垂直领域验证了它。问题是它是否能推广到垂直领域之外，还是会停留在垂直专属模式。
Skills 作为 packaging layer。GitHub 上 AGENTS.md 和 skills directories 的扩散，暗示了一种正在出现的 agent 能力打包方式。它是否会像 MCP 对工具那样标准化，是开放问题。
Claude Code 2026 年 4 月的质量回归及其复盘。一个行业领先的 agent 发布了 47% 的性能回归，而且是用户先于内部监控抓到它。这说明即使在领先者那里，生产 agent eval practices 仍然很不成熟。如果这推动全行业投资更好的 online evals，那这次修正是健康的。
Voice 作为默认支持界面。Sierra 的 voice channel 在 2025 年末超过了 text。如果这种模式在其他垂直领域持续，设计约束（延迟、打断、实时工具使用）会变成一阶问题，而大量当前架构需要返工。
Open-model agent 能力缩小差距。带 native thinking-into-tool-use 的 DeepSeek-V3.2。Qwen 3.6。更广阔的开放模型生态。窄 agent 任务的成本性能正在变化。闭源默认并不是永久的。
这些每一项都有一个明确答案：“六个月后我需要看到什么，才会相信它”。那就是测试。追踪答案，而不是公告。
非常规赌注
每个你不采用的框架，都是一次你不欠下的迁移。每个你不追逐的 benchmark，都是一个你保住的专注季度。在这一轮里获胜的公司（Sierra、Harvey、Cursor，在各自领域）选择了狭窄目标，构建无聊纪律，让领域里的噪音从身边经过。
传统路径是：选一个技术栈，花多年掌握它，爬梯子。当技术栈能稳定十年时，这很有效。现在技术栈每个季度都会变。正在赢的人不再优化技术栈熟练度，而是优化品味、原语和交付速度。他们公开构建小东西。他们通过交付来学习。他们被自己已经做出来的东西带进房间。凭证就是 artifact。
坐下来想一下，因为这才是整篇文章真正的重点。我们大多数人都是在一种工作模型里长大的：世界会稳定到足够让凭证复利。你上学。拿学位。爬梯子。在这里两年，在那里三年，简历慢慢变成能打开门的东西。整台机器都假设它另一侧有一个稳定行业。
Agent 空间现在没有稳定的另一侧。你可能想加入的公司只有六个月大。它们构建在上面的框架只有十八个月大。底层协议只有两年大。这个领域里一半被引用最多的文章，作者三年前还不在这个领域。没有梯子可爬，因为楼本身一直在改变楼层。当梯子不再有效时，剩下的是更古老的方法：做一个东西，把它放到互联网上，让作品介绍你。它非常规，因为它忽略凭证系统。它也是唯一能在移动领域里复利的方法。
从内部看，这就是这个时代的样子。就连巨头也在公开迭代，发布回归，写复盘，在线修补。今年交付最有意思东西的团队里，有些人十八个月前还不在这个领域。不会写代码的人正在和 agent 结对，交付真实软件。博士们被那些选对原语并开始挥棒的构建者超越。门是开的。大多数人还在找申请表。
你现在真正需要培养的技能不是“agents”。而是在一个表面不断变化的领域里，判断哪些工作会复利的纪律。Context engineering 会复利。工具设计会复利。Orchestrator-subagent 模式会复利。Eval discipline 会复利。Harness mindset 会复利。知道周二发布的那个框架的 API 不会。一旦你能分辨这些，每周的发布潮就不再像压力，而会变成可以忽略的噪音。
你不需要学习所有东西。你需要学习会复利的东西，跳过不会复利的东西。选一个 outcome。在发布前接好 tracing 和 evals。使用 LangGraph 或你团队里的等价物。使用 MCP。给 runtime 做沙箱。默认单 agent。失败模式把 scope 拉进来时再扩大。每季度重新评估模型。周五读三样东西。
这就是 playbook。其余是品味、交付速度，以及不追逐无关之物的耐心。构建东西。把它们放到互联网上。这个时代奖励做出东西的人，胜过奖励能描述东西的人。从来没有比现在更好的窗口，让你成为那个正在做东西的人。