本文来自微信公众号： 海外独角兽 ，作者：Celia、Siqi，编辑：Siqi
最近，harness engineering又成了继prompt engineering、context engineering之后新一代的buzzword。
这背后对应着一个越来越清晰的变化：当基模能力逐渐成熟后，现在真正决定agent上限的，已经不是模型本身，而是围绕模型搭建起来的整套系统。
尤其对于模型公司来说，谁更早把harness跑顺，谁就更早有机会捕获高质量的执行轨迹；谁能持续捕获这些轨迹，谁就更有可能形成更强的数据飞轮。
Deepmind的Staff Engineer Philipp Schmid甚至直接给出了一个判断：“The Harness is the Dataset.Competitive advantage is now the trajectories your harness captures(Harness本身就是数据集。现在真正的竞争优势，在于你的harness能捕获到怎样的执行轨迹).”
所以我们最近深入研究了一下这个概念，梳理了Anthropic、OpenAI、Google等一线团队的实践经验，也调研了一些身边顶级agentic engineering的经验感受，这里分享一些关键的方法论和思考。
01.
为什么Harness Engineering开始变得重要？
“Harness”一词来自马术，本意是马具的意思，放在这里非常贴切：模型就像一匹野马，同样是一股很强但不稳定的力量。人类用马具来限定马匹的行为、掌控前进方向，而harness就是人类驾驭模型能力的一套外围系统。
从时间线看，AI工程方法已经经历了三次演进：
•Prompt engineering（2022-2024）：关注如何表达需求，重点是打磨单次对话里的指令，研究怎么提问（e.g添加身份、场景、目的等细节）、给出示例，从而让模型理解任务，更稳定地给出想要的结果；
•Context engineering（2025）：关注怎么提供恰到好处的信息。随着任务变复杂，AI需要在有限的context window下了解所有的背景资料。所以，如何获取、压缩和组织上下文，成了新的工程实践重点；
•Harness engineering（2026）：关注如何“构建系统”，这里的“系统”可以简单理解为模型周围让它真正有用的所有部分：运行环境、工具调用、记忆系统、评估与回滚机制等等，相当于一个完整的运行环境+管控系统，能让Agent可靠、安全地完成任务。
如果要下一个定义的话，Agent=LLM+harness，如果说模型决定了要做什么，Harness决定了模型能看到什么、能用什么工具，以及失败时该怎么办。
这几层演进背后的共同逻辑是：一旦模型能力过线，瓶颈就会开始外移。
而这一次外移的一个标志性事件，是2025年11月Claude Opus 4.5的发布。它意味着模型的agentic能力到了一个tipping point，以至于“用好模型的能力”，开始比“提高模型的能力”，更加重要。也就是说，智力本身不再是瓶颈，瓶颈转移到了系统层。
我们团队最近在湾区交流下来，一个很直接的感受是，顶尖的工程师在那个节点其实都受到了不小的冲击。有人认真评估后说：我不用再招人了。(不过很有意思的是，当时市场热议的则是Gemini 3，真正认真讨论Opus 4.5的人反而没那么多。但现在回头看，Opus 4.5带来的影响，比Gemini 3更加深远。）
02.
Harness的6个关键组件
关于harness的组件目前在工程实践中还没有绝对共识，但综合目前看到的不同实践，我们认为它大致包括了以下6个部分：
1.Memory&Context management(记忆与上下文管理)：这一层解决的是“在当前时刻，Agent应该看到什么信息”。常见做法包括上下文裁剪、压缩、按需检索，以及外部状态存储等。
2.Tools&skills(工具与技能)：负责扩展Agent的行动能力。工具提供可调用的外部能力，skills提供可复用的任务方法。
3.Orchestration&Coordination(编排与协调）：也就是编排整套任务流程，协调每个agent的分工，决定何时规划、何时执行、何时交接，让复杂任务能被拆开、推进并收敛。
4.Infra&Guardrails(基础设施与保障)：负责提供运行环境和边界条件，包括沙箱、权限控制、失败恢复和安全护栏等，确保Agent能在真实环境中安全、稳定地运行。
5.Evaluation&Verification(评估与验证）：对于很多复杂任务来说，决定最终成效的往往不是第一次生成，而是有没有验证闭环。所以很多harness内置一套测试、检查和反馈机制，让Agent能自行验证自己的工作，并在发现问题后及时修正。
6.Tracing&Observability(追踪与观测）：负责还原Agent的行为过程，让整个黑箱变得尽量透明可见，例如提供执行轨迹、日志、监控和成本分析等能力。只有当这些过程是可见的，系统才是可调试、可优化、可管理的。
从完成一项真实任务的视角看，这6个组件其实对应着一条很清晰的链路：先准备信息，再推动执行，最后复盘结果。所以顺着这条逻辑，它们又可以进一步归成3层：信息层、执行层、反馈层。
举个具体的例子，Openclaw的爆火很大程度上就是harness engineering的一次胜利：它并不依赖模型能力，而是完全靠harness的设计创造出了aha monument。Openclaw的核心亮点就是几个工程组件：
•Gateway负责破壁，它把WhatsApp、Discord等社交软件统一对接给了模型，让小龙虾能像朋友一样出没在任意窗口。
•内置Skills库提供了一个趁手的百宝箱，给了它丰富的能力集合。
•记忆机制让它能持久地积累经验、不断进化。
•Heartbeat补齐了AI的“主观能动性”，让它能定时、自发地醒来干活。
•Soul.md等身份文件则是画龙点睛，给这些冷冰冰的代码注入了一个鲜活的人格。
每个组件单看都不复杂，但当这些微小的创新被巧妙地糅合在一起时，跨平台的存在感、主动发起对话的意愿、持续进化的记忆——这些模型本身没有的生命力就出现了。
03.
Harness的设计原则
这里我们尝试着总结一些Harness engineering的核心原则。它们不仅仅适用于agentic engineer，也适用于每一个想用好Claude Code/Codex的知识工作者(如果你还没用上的话，还是强烈推荐大家试用一下，彻底改变工作范式！)
总体上，今天Agent最大的瓶颈还是上下文长度的限制，所以harness的构建基本都围绕这条线展开的。而具体到信息层、执行层和反馈层，因为工程和任务目标的差异，又有着不同的设计原则：
信息层：帮Agent任务做资源准备
信息层解决的问题听起来很简单：给agent提供它需要的信息。但在实践中，这却是最容易犯错的地方，且错误原因往往不是给得太少，而是给得太多。因为模型存在context decay（上下文衰减）的问题，随着上下文不断变长，模型并不是线性地“知道得更多”，而是更容易被无关噪音分散注意力，导致对关键信息点的利用效率下降。
因此，信息层设计的核心原则是：精准，比求全更重要。落实到工程上，通常会对应到下面几种路径：
Trick 1：渐进式披露
简单来说，就是把信息做成“分层加载”的系统，让模型在不同阶段只接触当下需要的那一层，而不是一次性把所有信息都塞给AI。
比如，OpenAI就曾试着用一个巨大的AGENTS.md把所有规则写全，但后来发现并不可行。Context资源是极其稀缺的，一个巨大的指导文件会占据AI的脑容量，让它忽视真正重要的信息。
所以现在业内的最佳实践是通过文件系统来做分层披露，以Claude code为例，它把核心信息做了三层分级：
•Level 1 CLAUDE.md：这一层只放最关键、最常用的元规则。它更像一个总入口，用来告诉模型：这个项目最基本的情况是什么，应该遵循哪些原则，不同类型的任务大概该去哪里找资料。
•Level 2：SKILL.md：这一层更像按需调用的小型能力包。只有在特定任务出现时，模型才会去加载对应的skill，学习这项任务的做法。
•Level 3：reference、supporting files、脚本等：到这一层，模型接触的就不再是抽象原则，而是完成当前任务真正需要的细节：比如说明文档、操作示例、架构信息、日志、配置文件、测试命令，或者直接运行脚本后拿到的结果。
本质上，渐进式披露就是控制信息的出场顺序，让模型的注意力始终集中在当前最关键的1%信息上。
Trick 2：Tools越少而精越好
这一点其实相当反直觉：随着模型能力的提升，它对外部工具的依赖应当是递减的，而不是越加越多。
Agent的强大不在于工具箱里有多少把扳手，而在于它是否拥有几把完美的“万能扳手”，以及如何高效地组合它们。与之相对的，过于复杂的工具是模型幻觉的温床。一个常见失败模式就是工具集越加越多，导致agent陷入决策瘫痪。
Claude Code目前有大约20个工具，即使如此，他们团队也一直在审视是否真的需要所有这些工具，并且在非常谨慎地增加新工具。
Vercel团队他们最初给agent配备了涵盖搜索、代码、文件、API的完整工具库，结果表现很差；精简到只保留核心工具之后，速度和可靠性都显著提升。
Trick 3：找到Context window利用率的“甜蜜区间”
很多独立的工程实践都得出了一个相同的发现：当上下文利用率超过一个区间之后，性能就会开始下降。也就是说，给agent塞太多历史记忆和背景信息，不会让它更强，只会让它更糊涂。
具体的sweet spot根据模型、context window、任务类型的不同会有差异，比如下图是一个最新的大海捞针测试，我们可以看到，当输入token数量从256K逐渐拉满到1M时，几乎所有主流大模型的表现都出现了明显下滑。
表现最好的模型(Opus 4.6系列)，长上下文下还能维持七成的检索命中率，表现没那么稳的模型(GPT-5.4、Gemini 3.1 Pro)，命中率会直接掉到三成。
至于为什么有效的context window通常没有大家想象中那么长？一个核心原因是Attention的“稀疏性”。随着context变长，模型的注意力会被摊薄到更多位置上。它虽然看见了更多token，但未必还能稳定地把注意力放在最关键的那几个点上。如果关键的bug埋在中间，又有大量无关噪音干扰，它获得的权重可能不足以触发模型的警醒。
所以很多顶级工程师会频繁进行上下文压缩，把context window利用率控制在60%以下。
Trick 4：利用subagent做context隔离
当主agent的context开始变重时，把子任务分配给独立的subagent也是一个可行的方法。
每个subagent都在更小、更干净的context里完成自己的任务，少受无关信息干扰。等它们各自产出结果后，再回到主agent统一汇总和编排。
Claude Code负责人Boris Cherny把这套方法叫做context firewall。当遇到复杂任务时，他会直接让主agent“use subagents”，把看日志、查代码、搜文档这些事情并行拆开，主线程自己只做两件事：调度，以及收口。
执行层：给Agent一套执行规划
如果说信息层关心的是“给agent什么信息”，那么执行层关心的就是“让agent怎么做事”。这一层最常见的一个问题，是任务结构本身设计得不对。
Trick 5：把研究、计划、执行、验证分开
我们在学习top AI labs的实践经验时，会发现一个很普遍的做法，他们会刻意把一条任务链拆开，分成四步：research→plan→execute→verify，每个阶段是单独的session，有单独的context，而不是期待它一气呵成。
这背后同样是因为，Agent脑容量有限，把四个阶段压进同一个context，本身会造成一些不必要的context污染。所以用尽量用更多算力，完成更简明清晰的任务。
举个例子，假设我们要给产品增加一个身份验证系统，最好不要直接下达一个指令：“给我做一个身份验证系统。”更好的做法是：
(1)先开一个research session，专门研究各种可能的实现方案
(2)确定最终采用的行动方案(可以你自己来，也可以让另一个Agent决定，Claude code团队中有一个人的工作流就是：先让一个Claude写计划，然后再启动第二个Claude，站在staff engineer的视角来做评审）
(3)开一个全新的session，专门负责执行这个具体方案
做其它类型的任务也是一样，先让Agent研究最佳实践，再列出详细的执行计划，最后执行，效果往往更好。
Boris Cherny的CLAUDE.md里就有一条明确的规则：
Enter plan mode for ANY non-trivial task(3+steps or architectural decisions).If something goes sideways,STOP and re-plan immediately—don't keep pushing.
(只要任务不算简单，比如步骤超过3个，或者牵涉到架构层面的判断，就先做规划。一旦发现哪里不对，就立刻停下来重新做一遍规划，不要硬往下推。)
他在26年1月还又做了一层强化：用户接受计划之后，Claude Code会自动清空context，让执行阶段从一个干净的起点开始。他的观察是，执行阶段如果继续背着研究阶段留下的大量上下文，很容易被噪音干扰；反过来，把研究和执行切开，反而更能保证计划被准确落实。
Trick 6：人最该介入的地方，不是事后审核，而是事前规划
绝大多数人类用户只喜欢验收结果，而不重视前期的规划设计，但实际上，人恰恰应该把精力从事后的code review，尽量前移到research和plan这两个杠杆更高的环节。因为一行糟糕的代码，影响的可能只是一行；一行糟糕的计划，往往会长出几百行糟糕的代码。
越是上游环节，带来的单位时间的影响越大。
反馈层：Agent的复利飞轮
前两层决定了agent能做什么，反馈层决定的是系统随时间能变得多好。这是三层里最容易被忽视、也最能产生复利效应的一层。反馈层的核心逻辑，其实就是harness engineering这个概念最原始的定义。Mitchell Hashimoto在自己的blog中是这么写的：
Anytime you find an agent makes a mistake,you take the time to engineer a solution such that the agent never makes that mistake again.
这背后是一种工程纪律：每一次失败都不是终点，而是一次让系统永久变好的机会。他的做法是，每一次真实翻车的问题，都会被他尽量记到AGENTS.md里。包括Claude Code团队也会全员共同维护一个CLAUDE.md，只要Claude做错了一件事，就把这条经验补进去，让它下次不要再犯同样的错误。
Trick 7：构建反馈闭环
在Harness Engineering中，最能产生复利效应的投入，就是为Agent构建一套自动化的反馈与校准机制。
Boris Cherny分享过一个数据：只要给Claude提供有效的验证手段，其最终产出的质量通常能提升2-3倍。他的做法包括：
•任务完成后，提醒另一个agent验证结果，或者开启stop hook自发校验。
•用ralph-wiggum插件把整个流程改成“自动迭代模式”，让Claude不断做、不断验、不过就继续，直到满足完成条件。
•让Claude自己打开浏览器、测试UI、反复迭代直到UX过关。
Karpathy最近提出的autoresearch的思路同样很有启发。
Autoresearch的重点不是让AI一次性想出最好的答案，而是让AI进入一个可控闭环：自主提出idea→做实验→观察实验结果→保留有效策略、丢掉无效分支→反思后继续提出不一样的改进策略→如此反复循环。
这其中，重点不在于单次输出能有多惊艳，而在于能不能给它设计一个能不断筛选、充分迭代的回路。而这类回路不仅仅是适用于research，也适用于大多数提高转化率、点击率、分数指标的场合。
04.
模型vs harness，究竟是怎样一个关系？
关于harness，所有人都在好奇的一个问题是：模型会吃掉脚手架吗？harness当下创造的价值多大程度上会被模型厂自己做掉？例如Claude Code和Codex，本质上其实就是模型公司的竞争已经从单纯的模型层，转向了“模型+harness”的整体。
这个问题很难在今天直接给出一个明确答案，因为模型和agent实践的变化相当迅速。但可以确定的是，模型和harness的耦合程度是比多数人想象得要深的。
训练即部署
Agent能力的上限，越来越由环境质量决定，而不只是模型本身，所以在agentic RL的训练逻辑里，模型和harness从一开始就不是分开设计的。
如果没有参与过agent开发，那么大多数人对于“开发一个agent”这件事的第一反应可能是：先训练一个能力过关的模型，再给这个模型接工具、接工作流等等。也就是说，模型是主体，harness是后装件。
但agentic RL的训练逻辑和这个直觉正好相反。普通chatbot的RLHF是单轮的，奖励信号密集，反馈直接。Agentic RL则非常不同，它涉及到：
•多轮、长链路、带工具调用(且一次rollout可能调用上百次工具)
•动作空间极大
•奖励信号非常稀疏，复杂任务可能1000次尝试才成功一次
•很依赖真实环境中的反馈，比如测试有没有通过、代码跑没跑起来、lint报没报错
……
这也意味着，训练效果在很大程度上取决于“训练场设计得好不好，像不像真实世界”。模型在训练阶段看到什么，往往就是它上线之后真正要面对什么。它在训练时用的是同一套工具、同一种终端、同一类沙盒，接受的也是同一类反馈。
比如，Cursor在训练Composer 1.5时，用的几乎就是一套面向真实用户服务的coding环境。它会并发跑数十万个沙盒，让模型在里面反复试：先搜什么，读哪些文件，改多少代码，什么时候该停下来做验证。
在这个过程中，他们发现模型自发涌现了很多能力：
•它开始学会在复杂代码库里做更深入的搜索
•会顺手修掉linter错误
•会自己补单元测试，再执行验证
•也会从一开始动不动大改一片，慢慢转向先多读、少乱改
Windsurf在训练SWE-1.5时，表达得更直接。他们在技术博客里写道：
“We believe that the quality of the coding environments in RL tasks is the most important factor for downstream model performance.”
(我们认为，在RL过程中，coding环境本身的质量，对模型最终表现的影响是最大的。)
“Our vision is to co-optimize models and harness:we repeatedly dogfooded the model,noticed issues with the harness,made adjustments to tools and prompts,and then re-trained the model on the updated harness.”
(我们的思路是把模型和harness当成一个整体来共同优化：一边反复使用模型，一边暴露harness中的问题，再去调整工具和prompt，最后基于新的harness继续训练模型。)
Harness的很多能力，在快速被模型吸收
理解了“训练即部署”这件事，就能理解harness为什么是一个奇特的行业：它一边创造价值，一边把自己的能力源源不断地输送进模型本身。
现在模型公司都在把“模型+harness”当成一个整体来优化。很多原本属于harness的能力，已经被模型逐渐内生化，比如tool search、programmatic tool use、compaction/summarization、多步工具调用策略等。这件事通常是这么发生的：
•模型团队和社区用户在前线摸索，试出哪些方法真的有效；
•随后训练团队把这些模式拿去做post-tarining，
•在这一过程中，模型开始把这些能力慢慢内化，一部分原本必须靠harness强行维持的能力，开始变成模型自己的能力；
•新的harness又被重新设计出来支持新的模型能力...
•如此循环往复。
如今的很多harness能力，比如planning、self-verification，也都在公开采访里被透露过，可能会成为未来后训练的候选方向。
Claude Code负责人Boris Cherny也说过，Claude Code的harness在不断被重写，里面每行代码的保质期可能也就2个月。
Harness即数据
Deepmind的Staff Engineer Philipp Schmid有一个金句：“The Harness is the Dataset.Competitive advantage is now the trajectories your harness captures(Harness本身就是数据集。现在真正的竞争优势，在于你的harness能捕获到怎样的执行轨迹).”
现在真正有价值的数据，不再只是静态语料，还包括了agent在具体业务流程中跑出来的执行轨迹：它看到了什么信息，使用了什么工具，做了什么决策，哪一步容易出错，什么反馈会让它变得更好。
在这种情况下，harness不再只是模型外面的脚手架，而是模型能力生成的土壤，土壤的质量，会一定程度上决定和反哺智能的生长。
以Anthropic为例，它在harness上的探索比OpenAI领先了一段时间，但就是这几个月的窗口期给了它巨大的机会。
现在市场的情况是：即使目前的模型水平两家已经基本打平了，但大多数人依然在用Claude Code。
同时，模型和应用的竞争也呈现了一种很有意思的态势，头部的模型公司在端到端做harness，而应用公司也越来越多开始自己训模型。
我们发现现在湾区已经有很多大的AI应用公司(远不只是coding方向)在搭建自己的continuous learning平台，基于自己的harness和业务数据，做开源模型的RL，并且已经开始从头部AI labs迁移模型用量。
他们认为，在很多垂直场景里，今天的开源模型能力已经够用了。接下来的差距，未必来自谁有更好的模型，而是来自谁能围绕具体任务，把模型、任务结构、反馈闭环和后训练结合得更好，在特定场景里做出成本更低、效果更好的系统。
这种竞争格局，可能会成为接下来几年AI竞争里最有趣的看点之一。
05.
创业公司的机会
随着harness的重要性逐渐提升，我们相信这个领域也会有一些创业公司的机会，以下整理了一些比较有代表性的，势头非常好的项目，他们最近也都拿到了知名机构的大额融资。
信息层
今天企业应用AI的最大瓶颈之一，是agent没有充分的背景信息，所以怎么以agent为中心抓取出企业里原本分散的、隐性的知识，会是一个新的创业机会。我们尚不确定它最终能不能成长为一个大的独立赛道，但这些玩家起码是2B巨头们很好的收购标的。
代表公司：Edra
Edra把自己定位为“Context for Agents at Scale”，专注于把企业里分散的流程知识变成agent可执行的动态上下文，会自动读取企业现有的tickets、logs、emails、chat histories等数据，然后并行运行数千个智能体来探索这些数据、模拟决策并综合得出反向推理流程，还原公司真实的做事流程，再整理成一套agent可以复用的playbooks。官方slogan是“Edra learns how your business operates.Then automates it.”
今年3月，公司完成了约3000万美元A轮融资，Sequoia领投。
执行层
方向1:Workflow orchestration/durable execution
代表公司：Temporal
Temporal是做Durable Execution的底层infra，简单讲就是让很长、很复杂、很容易失败的任务，依然能稳定跑完。中间哪怕服务器挂了、网络断了、任务等了三天，它也能记住执行到哪一步，然后从断点继续。
未来随着Agent需要完成越来越复杂，长时的任务，尤其是当未来成千上万个Agent要互相通信和交易时，对状态管理与失败恢复的要求会越来越高。这种分布式系统的运维非常复杂，而Temporal在这方面有深厚的技术积累和很强的先发优势，所以签下了OpenAI、Replit、Netflix、Stripe、Datadog、Snapchat、JPMorgan等很多大客户。
26年2月，公司完成了3亿美元D轮融资，a16z领投，估值50亿美元。
方向2:Security/Governance
代表公司：Oasis Security
Oasis是面向agentic enterprise的权限管理平台。它想解决的问题是：现在企业里越来越多去访问系统、调用数据的，是AI agent。但很多公司并不清楚这些“数字身份”到底有多少、分别在做什么、权限是不是开得太大、出了问题又该找谁负责。Oasis就希望帮企业建立一套安全管理系统，让agent能拿到完成任务所必要的权限，但同时又不产生过多风险，并且让整个过程可以被追踪和控制。
26年3月，完成1.2亿美元B轮融资，Craft Ventures领投，Sequoia、Accel等跟投，估值7亿美元。
方向3:Sandbox
代表公司：Daytona
Daytona做的是agent的沙箱基础设施。它和E2B的区别在于，E2B更像“给agent一个安全的执行盒子”，Daytona更像“给agent一台可长期使用的电脑”。
至于为什么这个节点需要Daytona这类沙箱？核心是因为最近这一波产品，比如Claude Code、Codex，把新的agent产品形态带火了，ai开始需要真的像员工一样有一个workspace持续工作，就会催生一层专门的沙箱基础设施，这个环境不是一次性跑完就销毁，而是stateful的，能让agent展开更长周期、更复杂的工作流。
2026年2月，公司完成2400万美元A轮融资，FirstMark领投，Pace、Upfront、Datadog、Figma Ventures等跟投。
反馈层
Evaluation&Obervability也是我们相对看好的一层，原因有三点：
1.企业需要一层独立的质量控制面板，通过它看到真实调用链路、比较不同模型和版本。(虽然OpenAI和Anthropic的企业级平台也都在内置eval、trace的能力，且未来有一天也可能支持接入第三方模型，但对企业来说，底层模型和评测体系如果都出自同一家，始终会有顾虑，所以它相对不容易被模型厂吃掉）
2.这是当前AI企业的刚需痛点，且未来随着Agentic层的复杂度变高，Agent完成的任务变长，对observability&evaluation的要求也会越来越高、越来越精细。
3.这一层通常会深度嵌入企业的AI工作流。它不只是一个看板，而是会进入数据采集、评分标准、版本发布和回归测试流程。接进去之后，替换成本往往不低。
代表公司：Braintrust
•产品：
定位是一个给AI产品团队用的AI observability/evaluation平台。产品可以简单理解成三步：
(1)看清过程。Braintrust会把AI应用在生产环境中的请求记录成traces，帮助团队看到一次调用里具体发生了什么，包括用户输入、模型输出、中间步骤、延迟，以及token和成本等信息，从而定位问题到底出在哪一层。
(2)判断好坏。团队可以用人工标注、规则或LLM scorer对结果做评分，判断回答质量。Braintrust同时支持离线实验和线上打分，让团队既能在发布前测，也能在真实流量里持续监控。
(3)持续优化：把线上真实出现的问题沉淀成测试集，用来比较不同prompt、模型等产生的不同效果，帮助团队方便地调试和打磨产品。
•融资：
26年2月，完成8000万美元B轮融资，ICONIQ领投，a16z、Greylock、Elad Gil、Basecase等跟投，估值8亿美元。
06.
What's Next？
如果把prompt engineering、context engineering和harness engineering放在一起看，它们其实很像一个初级员工的成长过程。
最开始，你只能和他做简单问答；再往后，你可以把完整的业务背景交给他，让他独立完成一轮深入调研；再往后，你开始给他工具、权限和反馈机制，让他自己拆任务、调工具，甚至带着几个subagents一起干活。
那我们不禁在想，再下一个范式会是什么？
在人类现实职场中，大部分人都会有相对明确的career path：从一名初级员工，逐渐积累经验，甚至升级为一个高管，从执行者变成规划者，带领几十个下属完成一个高度复杂的项目。
如果沿着人类员工的经验做一个自然推演，那么下一阶段Agents需要达到的，大概也是协调无数agent/人类节点共同完成复杂任务。
我们或许可以暂且叫做——Coordination Engineering。
OpenAI的工程负责人和产品设计师在1月底的一期播客采访里，也多次提到了他们在思考multi-agent networks。
“我不方便讲太多roadmap，不过有一个挺值得思考的问题是：一旦进入multi-agent世界，复杂度会迅速上升，那你怎么才能管理这一切？用户怎么才能始终知道每个agent在做什么、执行了哪些动作、流程推进到哪一步，以及中间哪些地方需要自己介入、授权或纠偏？”
所以从这个角度看，下一代AI产品未必是一个更聪明的小龙虾，而更像一个小龙虾版飞书，本质是一个有效的监工看板+一个能让各种节点有效协作的im平台。
最终这四个层级叠加起来，可能就构成了Agentic engineering的终极范式。它们之间不是一个替代关系，而是一个包含关系，智能的水位涨上来，“控制面"就开始不断上移：
•L1解决问答质量
•L2解决认知边界
•L3解决执行闭环
•L4解决组织协同
再往终极推演呢？一切似乎就只剩下了intention engineering，人的价值只剩下了“设定目标函数”，其余AI都可自行包揽。
到那时候再回头看，所谓的白领工作，可能真的是人类历史走过的一段弯路。