很多人现在还在把 Agent 工程理解成“提示词写好一点”“工具接多一点”“模型换强一点”。但真做过生产系统的人都知道，决定一个 agent 能不能长期稳定干活的，往往不是模型本身，而是模型外面那一整圈“缰绳系统”——它能看到什么、能调用什么、在哪跑、如何记住进度、出了错怎么自纠、哪些动作必须审批、结果怎么被验证、谁来追责。Harness engineering，本质上就是在设计这一整圈系统。 OpenAI 在讲 computer environment 时，把问题说得很直白：真正难的是中间文件放哪儿、大表别怎么别全塞进 prompt、网络访问怎么安全开、超时和重试怎么处理；Thoughtworks 则把 harness 拆成前馈引导和反馈传感器；OpenAI 的 agent eval 文档又把 traces、graders、datasets 和 eval runs 放到了工作流质量的中心位置。
如果要把几个容易混的概念分开，我会这样讲。Prompt engineering 主要解决“话怎么说”；context engineering 主要解决“什么信息进上下文、什么别进”；Anthropic 甚至明确把 context engineering 说成 prompt engineering 的自然延伸，因为 agent 是多轮、长时程、动态上下文系统。Harness engineering 则再往外走一层：它不是只管 token，而是把 context、工具、运行环境、状态持久化、验证、审批、安全、观测和持续改进，组合成一个可运行、可恢复、可纠偏、可治理的代理系统。也可以说，context engineering 是 harness engineering 的核心子集，但不是全部。
这个词之所以叫 harness，也不是凭空冒出来的。软件测试里早就有 test harness，IBM 文档把它描述成运行测试所需的测试用例、被测源文件、stubs 和配置集合；微软的 HLK 词汇表把它定义成自动化测试的软件应用；LLM 领域里，EleutherAI 的 lm-evaluation-harness 也是老牌项目，本质上就是统一评测框架。只不过到了 agent 时代，harness 不再只是“测试支架”，而是慢慢变成了运行时支架、控制面和反馈回路。
一、为什么这个词会在现在爆发
说白了，是因为瓶颈换地方了。OpenAI 在 Codex 的那篇文章里写得非常坦诚：他们做了一个极端实验，用 Codex 构建和交付一个内部 beta，五个月里仓库长到约百万行代码，估算速度大约是手写的十分之一；真正变化不是“AI 会写代码了”，而是工程团队的主要工作从“写代码”转向了“设计环境、表达意图、搭反馈回路”。这其实已经把 harness engineering 的核心说透了。
另一头，Anthropic 在 long-running agents 的实践里给了一个非常现实的提醒：跨很多个 context window 持续工作，本身就是个开放问题。 单靠 compaction 还不够，因为 agent 每次跨 session 都像换了个新同事，天然会丢失局部状态和工作感；所以他们才会设计 initializer agent、progress file、feature list、增量式 coding agent 这些东西，让后续 session 能像接班一样继续推进。
再往企业真实场景里看，问题会更明显。OpenAI 讲他们内部数据代理时提到，自家数据平台面向 3,500 多内部用户，覆盖 600 多 PB 数据和 7 万个数据集；难点已经不是“会不会写 SQL”，而是“能不能找到对的表、理解表间关系、避免 many-to-many join、filter pushdown 和 null 处理这些坑”。这类系统的失败，大多数时候不是模型智力不够，而是 harness 没把正确的数据语境、权限边界和验证闭环接上。
所以今天再看 agent，最靠谱的理解已经不是“一个大模型 + 几个工具”，而是下面这套分层系统：
在我看来，模型更像大脑，harness 更像操作系统、工作台和安全带的合体。你要的是一个能让模型稳定把事做完的系统，不是一段“看起来很聪明”的对话。这个判断，和 OpenAI 对 agent loop/工具/容器/状态的拆法、Thoughtworks 对 feedforward/feedback 的拆法，其实是同一路。
二、Harness Engineering 到底在工程上拆成什么
1）意图与上下文 Harness：先让 agent 看见正确的世界
很多团队一上来最容易犯的错，就是想靠一份巨长无比的系统提示词把一切讲清楚。OpenAI 在 Codex 的实践里明确说，这条路很快就会烂：一个“大而全”的 AGENTS.md 会很快过期、难验证、难维护，所以他们后来把 AGENTS.md 当目录用，把真正的系统知识放进结构化的 docs/ 目录，作为 repository 内的 system of record；进一步，他们强调的目标不是“人类可读性”而已，而是 agent legibility——代码库要让 agent 能够直接推理业务域。
这在数据代理场景里会更极致。OpenAI 的 in-house data agent 不是只吃 schema，它把上下文拆成六层：Table Usage、Human Annotations、Codex Enrichment、Institutional Knowledge、Memory 和 Runtime Context；离线侧每天把表使用、人工注释和代码推导出的语义聚合成统一表示，再做 embedding 和检索，运行时只拉最相关的上下文，必要时再去 live query 仓库或别的内部系统。这个设计特别值得数据团队研究，因为它说明 高质量 agent context，本质上是一套数据产品，不是 prompt 拼贴。
再往前走一步，就是把“组织知识”和“流程经验”做成可复用组件。OpenAI 在 computer environment 里讲的 Agent Skills，本质上是包含 SKILL.md 和资源文件的 folder bundle；Anthropic 也在 2025 年推出了 Agent Skills，并在同年把它开成跨平台标准。它的意义不是“又多一个提示模板”，而是把某个领域的程序性知识——比如怎么跑发布、怎么排查日志、怎么做审批流——从人的脑子里拿出来，封装进 agent 能发现、能执行、能继承的资产里。
但这里有个容易忽略的反直觉点：越是往 harness 走，越要尊重简单、可组合。 Anthropic 在《Building effective agents》里反复强调，最成功的 agent 系统通常不是靠复杂框架堆出来的，而是靠简单、可组合的模式；他们也提醒，框架层数太多会遮蔽 prompts 和 responses，让系统更难调试。这个建议特别重要，因为 harness engineering 很容易把人带进“再包一层抽象”的冲动里。讲真，很多时候你需要的是更清晰的 contract，不是更重的框架。
2）工具与环境 Harness：别只给工具，要给可控的工作现场
Agent 真正能做事，靠的不只是“有工具”，而是有一个能安全调用工具的现场。OpenAI 的工具文档把范围讲得很清楚：built-in tools、function calling、tool search、remote MCP 都是扩展模型能力的手段；MCP 则把外部系统接入做成了开放标准，核心对象是 resources、tools 和 prompts。MCP 官方直接把自己比喻成“AI 的 USB-C”，这个比喻虽然有点营销味，但方向没错：未来 agent 连接外部世界，不会靠一堆私有 SDK 各写各的，而会越来越依赖统一协议层。
不过工具不是越多越好。OpenAI 的 MCP 指南专门提醒：远端服务器常常一下暴露几十个工具，名字、描述、schema 全塞进上下文会显著增加 token 开销和延迟，所以建议用 allowed_tools 把模型真正能看到的动作集合收紧；运行时还会缓存工具列表，避免每轮都重新拉。这个建议特别符合真实生产经验：对 agent 来说，模糊的可选动作本身就是噪声。 工具过多，往往不是能力更强，而是 decision space 更乱。
工具之外，更重要的是运行环境。OpenAI 在《From model to agent》里把问题拆得很实：agent 需要放中间文件的地方、需要结构化存储、需要网络访问，但这些能力又不能无限裸开。所以他们的 hosted container workspace 提供了文件系统、可选的 SQLite 这类结构化存储、受限网络访问，再通过 sidecar egress proxy 做 allowlist、访问控制和按域注入 secrets。这里最值钱的不是某个具体实现，而是一个工程原则：不要把工作状态都塞进 prompt，要把它放回文件、数据库和受控运行时。
MCP 本身的授权模型也越来越像企业级系统，而不是开发者玩具。官方授权文档建议，对访问用户数据、需要审计和有严格企业访问控制要求的场景，MCP server 应该走 OAuth 2.1 这类标准授权流程。也就是说，今天你设计 harness，不能只考虑“工具能不能调起来”，还得从第一天就把 who can do what 做进协议层。
3）编排与状态 Harness：让 agent 不只会动，还能持续干
很多人第一次做 agent，会把 orchestration 理解成“模型出一步，我执行一步”。这只是最薄的一层。OpenAI 的 Responses API 文章其实讲得很完整：agent loop 不只是工具调用，而是模型提出动作、平台执行、结果回灌、再决定下一步的持续循环；长任务还需要 compaction，否则上下文迟早打满。LangGraph 也把 durable execution 说得很直接：长时任务、会中断的任务、需要 human-in-the-loop 的任务，本质上都需要把进度保存到持久层，才能暂停后原地续跑。
OpenAI 后来又把 Codex 的 harness 协议化成了 App Server，这个动作很有代表性。它把 agent loop、线程生命周期、配置、鉴权和事件流，统一暴露成稳定的 JSON-RPC 界面；Web 端之所以能在标签页关掉、网络抖动后继续干活，本质上是因为任务状态不再放在客户端，而是放在服务端线程里，客户端随时可以 reconnect。更进一步，OpenAI 还专门提到，未来 TUI 连接远端机器跑 Codex，可以让 agent 靠近算力，即便本地笔记本休眠也能继续执行。这个细节很说明问题：一旦进入生产，agent 的“会话”更像作业，不像聊天。
Anthropic 在 long-running harness 上给出的做法也很值得借鉴。他们把跨多 context window 的问题拆成 initializer agent 和 coding agent：第一个 session 负责建立 init.sh、progress file、初始 commit 和 feature list；后续每个 coding session 只做一个增量 feature，开始前先读 git log 和 progress file，结束时写清楚进展，并把有意义的状态 commit 回去。这个模式听起来土，但特别有效，因为它把“短期上下文记忆”替换成了环境里的持久工件。
再细一点，编排层还得有事件拦截和回滚能力。Anthropic Agent SDK 里的 hooks 可以在工具调用、session 启动、执行停止等关键点插入自定义逻辑，比如阻断危险命令、记录审计日志、注入凭证、要求人工审批；文件 checkpointing 则能把通过特定编辑工具产生的改动记录下来，方便回滚到之前状态。LangGraph 的 HITL middleware 也支持在工具执行前发 interrupt，人工做 approve、edit 或 reject，然后沿着同一 thread 恢复执行。说得简单点，好的 harness 不是只会“跑”，还得会“停”“看”“改”“撤” 。
三、真正的 Harness，不是只有输入控制，还得有验证闭环
Martin Fowler/Thoughtworks 对 harness 的一个拆法我很喜欢：feedforward guides + feedback sensors。前者是在生成前给 agent 正确引导，比如规则、how-to、技能、脚手架、codemod；后者是在生成后不断验错，比如 lint、测试、结构检查、日志、浏览器、review agent。她还专门区分了两类控制：computational 的是 deterministic、快、可靠的，比如 tests、linters、type checkers；inferential 的是语义性、概率性的，比如 AI code review、LLM-as-judge。这组分类很重要，因为它直接决定你应该把什么放在前面，什么放在后面。
这也是为什么我一直觉得，很多团队今天不是“不会做 harness”，而是验证层顺序放反了。他们会先堆 review agent、AI judge、复杂 evaluator，却没有基础的结构测试、lint、边界约束和最小回归集。Thoughtworks 那篇文章反复强调“keep quality left”，把便宜、快速、确定性的控制尽量左移；Anthropic 也说过“先找最简单的方案，只有真的不够时再加复杂度”。这两个建议放在一起，几乎可以当 harness engineering 的第一原则。
现在主流平台也越来越把验证做成一等公民。OpenAI 的 agent eval 文档把 traces、graders、datasets 和 eval runs 放成一套工具链；trace grading 直接定义为给 agent 的 end-to-end trace 打结构化分数和标签，用来识别到底是模型、工具、编排还是 guardrail 出了问题。Anthropic 对 agent eval 的提醒也很实用：多轮、带工具的 agent 比单轮问答更难评，因为你不能只看最终答案，还得看它过程中调用了什么、在哪一步偏掉了。
数据代理这类系统更能说明验证层的重要性。OpenAI 的 in-house data agent 用的是带“golden SQL”的 eval：每个关键问题都对应人工写的基准 SQL，把 agent 生成的 SQL 跑出来，再和基准结果做 SQL 和数据层面的双重比较，像持续跑单元测试和 canary 一样去盯回归。这一点非常值得数据团队抄作业，因为在数据场景里，最终自然语言答得顺不顺，不如底下 SQL 和结果集对不对重要。
Anthropic 的 long-running application harness 则把验证再往前推了一层：它不是等应用写完再验，而是设计了 generator-evaluator loop，先由 generator 写，再由 evaluator 通过 Playwright MCP 真点真测，包括 UI、API 和数据库状态；每个 sprint 之前先谈 sprint contract，明确这一轮“done”长什么样。官方案例里，solo 跑 20 分钟大概花 9 美元，full harness 跑 6 小时大概花 200 美元，成本明显更高，但输出质量也显著更好。不过 Anthropic 也很诚实地说，随着底模能力提升，evaluator 的收益会向“更靠近边界任务”的地方收缩，不是所有任务都需要一样重的 harness。
四、没有治理，Harness 迟早会变成事故放大器
一旦 agent 真能读文件、发请求、写数据库、改代码，治理层就不是“加不加”的问题，而是“先做哪种”的问题。OpenAI 在内部数据代理里把安全边界设计得很清楚：agent 只是界面层，权限是严格 pass-through 的，用户本来能查什么它才查什么，没权限就退回到可访问的数据集；同时它会把执行假设和底层结果链接展示出来，方便人复核。这个设计很像成熟 BI 系统的安全模型：代理不应该创造权限，它只应该继承权限。
工具面也一样。OpenAI 在数据代理复盘里专门提了一个教训：早期给 agent 暴露了太多重叠工具，结果可靠性反而下降，所以后来主动收缩和合并工具面。这个教训和 allowed_tools 的建议其实是同一件事：人看到两个近似工具会自己判断，agent 往往只会困惑。
Anthropic 在 auto mode 上给出的数字也很说明现实：Claude Code 用户会批准 93% 的权限提示，这说明单纯靠人工点“批准”会很快走向 approval fatigue。为此他们做了两层防线：输入侧的 prompt-injection probe 扫描工具输出，发现可疑内容就先在上下文里加警告；输出侧的 transcript classifier 对工具调用做决策，必要时再进入更贵的推理阶段。更有意思的是，他们还列出了内部 incident log 里的真实误行为例子，比如误删远端分支、误上传认证 token、试图对生产数据库做迁移。这个案例说明，治理层真正要防的，很多时候不是“邪恶 agent”，而是过于热心、看起来很合理、但越权了的 agent。
OpenAI 的 observability / MCP 指南也给了一个很务实的分工：公共远端服务可以用 hosted MCP；但如果你的运行时要自己接管连接、过滤和审批，那就该用 local 或 private MCP。换句话说，审批和连通性本身也是 harness 的一部分，不是工具之外的“运维问题”。
五、Entropy 管理：很多 harness 不是死于第一次失败，而是死于慢性变脏
这部分我觉得是很多人最容易忽略、但实际上最“架构师”的一层。OpenAI 在 Codex 的文章里直接用了 “entropy and garbage collection” 这个说法：agent 会放大仓库里已有的模式，哪怕那些模式并不均匀、甚至并不好；他们一开始靠人每周五花 20% 时间清理 “AI slop”，后来发现这根本不 scale，于是把“人类审美和规则”抽出来，做成持续清理和约束机制。与此同时，他们还调整了 merge 哲学：在 agent 吞吐远大于人类注意力的前提下，过重的 blocking gate 反而会拖垮效率，很多问题用后续小修比长时间阻塞更划算。
Thoughtworks 的视角和这个正好对上。她把 drift sensors 单列出来，指出一些问题不是跟随单次变更出现，而是慢慢堆出来的，比如死代码、覆盖率质量、依赖老化、运行时 SLO 劣化、日志异常。更关键的是，她明确说了：构建 outer harness 正在变成一种持续工程实践，不是一次性配置。这个判断我非常认同。因为 harness 不是文档、不是模板、不是某个 SDK 开关，它本质上是一个随系统共同演化的控制系统。
六、从 Data+AI 的角度看，Harness Engineering 本质上是数据工程问题
很多人把 harness engineering 归到“AI 应用层”，我觉得这看轻了它。站在 Data+AI 的角度，harness 的上游其实是一堆非常典型的数据资产：元数据、血缘、历史查询、人工注释、组织文档、权限模型、运行日志、trace、评测集、memory store、预算记录、审批记录。OpenAI 的数据代理之所以有竞争力，不是因为它“会说”，而是因为它后面有一个每天聚合表使用、人工语义和代码语义，再做 embedding 检索的 context pipeline。你要是把这层删掉，再强的模型也会在 7 万个数据集里迷路。
所以在我看来，harness engineering 正在把几种原本分散的角色重新拢到一起：数据工程负责把上下文做成可检索、可权限控制的数据产品；平台工程负责把工具、容器、线程、审计、审批这些运行时能力搭起来；AI 工程负责把 agent loop、skills、eval 和自我修正做好。也就是说，agent 的可靠性，不再只是模型层问题，而是一个典型的数据+平台+应用三层协同问题。
这里我特别想强调一个方法论：把状态落成工件，而不是堆在上下文里。 Repository docs、progress file、SQLite、thread history、checkpoint、评测样本、trace store，这些东西都应该被当成“可管理的状态”；prompt 只负责把 agent 指向这些状态，不负责承载全部状态。OpenAI 用 docs/ 和 AGENTS.md 做知识地图，Anthropic 用 progress file 和 git commit 做 session 交接，OpenAI 的 computer environment 用 SQLite 和文件系统承载中间数据，App Server 用线程历史做可重连会话，这些做法背后都是同一条原则。
一个我比较认同的企业级 harness 蓝图，大概会长这样：
goal:
business_domain: growth-analytics
success_criteria:
- answer_is_traceable
- sql_is_reproducible
- side_effects_are_audited
context:
sources:
- docs/
- metadata_catalog
- query_history
- human_annotations
- memory_store
runtime_retrieval: rag + live queries
tools:
allowed_tools:
- search_docs
- query_warehouse
- read_notion
- generate_notebook
environment:
sandbox: container
storage:
- filesystem
- sqlite
network:
allowlist_only: true
verification:
deterministic:
- unit_tests
- schema_checks
- sql_checks
inferential:
- review_agent
- trace_grader
governance:
auth: pass_through
approvals:
- sql_write
- external_post
- destructive_shell
observability:
- traces
- cost
- latency
- tool_audit
七、企业里真正的应用，不是“炫技”，而是这些硬场景
1）Coding Agent：从“AI 写一点代码”升级成“AI 驱动的软件工厂”
OpenAI 的 Codex 实验是这个方向最有代表性的案例之一。他们公开写了几个很硬的数字：内部 beta 产品五个月做出约百万行代码，所有应用逻辑、测试、CI、文档、观测和内部工具都由 Codex 写成，约 1,500 个 PR 被打开并合并，平均吞吐达到每位工程师每天 3.5 个 PR，而且官方估算总耗时大概是手写的十分之一。需要强调的是，这些都是 OpenAI 自己披露的内部数据，不是独立第三方 benchmark；但它至少证明了一件事：当 harness 设计得足够好时，工程吞吐的上限会被明显抬高。
2）Data Agent：从“帮你写 SQL”升级成“带着组织语境做分析”
OpenAI 的数据代理案例我觉得对企业更有普适性。 它不是让 agent 自由发挥去猜表，而是通过多层语境、持续记忆、权限继承和 golden SQL eval，让员工从自然语言问题直接走到分析结论，而且官方说这个过程把“从问题到洞察”压缩到了 minutes, not days。对大多数企业来说，这类场景的价值比 coding agent 更直接，因为它正好打在了组织里最昂贵的地方：知识分散、表多、口径乱、权限复杂。
3）长时程应用开发：从“单轮生成网页”升级成“多阶段、可验收的开发工作流”
Anthropic 的 full harness 案例也特别能说明问题。单个 generator agent 当然能快速出点东西，但一旦你要的是“能用的应用”，就需要 evaluator、Playwright MCP、sprint contract、bug 反馈、逐轮修正这整套闭环。官方案例里，full harness 比 solo 明显更贵，但输出质量也更像一个真实可交付物，而不是一张好看的 demo 图。这里真正值钱的不是多 agent，而是把‘完成定义’、‘测试动作’和‘纠错回路’全都系统化了。
八、落地时最容易踩的坑，我建议你提前避开
第一，别把 harness engineering 理解成“高级 prompt engineering”。
Prompt 很重要，但它只是最里面那层。真正决定系统能不能长时间可靠工作的是上下文检索、工具过滤、持久状态、验证闭环和权限边界。只调提示词，不搭 harness，通常只能做出看上去聪明、但不耐跑的 demo。
第二，别把所有工具都暴露给 agent。
OpenAI 在数据代理和 MCP 指南里都讲了同一个教训：工具过多会制造歧义、增加 token 和延迟，还会让模型更难做决定。生产里更稳的策略通常是：少而精的工具集 + 明确的 allowed list + 清晰的 tool contract。
第三，别把状态只留在会话里。
真正能持续跑的 agent，一定会把状态沉淀成环境工件：docs、feature list、progress file、SQLite、thread history、checkpoint。Anthropic 的 long-running harness 和 OpenAI 的 App Server / computer environment 都在用这条路。
第四，别一上来就依赖 AI judge，先把 deterministic control 补齐。
lint、结构测试、边界校验、最小回归集、权限检查，这些东西依然是底座。LLM review 很有用，但它更适合补语义判断，不适合替代全部工程控制。
第五，别让 agent 凭空拥有比用户更大的权限。
无论是数据代理的 pass-through security，还是 MCP 的 OAuth 2.1 授权，再或者 Anthropic 对危险操作的 classifier gating，方向都非常一致：agent 最好继承用户权限、遵守组织边界，而不是自创一套万能后门。
第六，别只评最终答案，要看 trace。
Agent 错误往往不在最后一句话，而在中间某次工具调用、某次错误假设、某次越界动作。Trace grading、tool audit、OpenTelemetry、session logs，这些东西不是 nice-to-have，而是定位问题的主战场。
九、Harness Engineering 的商业价值，到底值在哪
很多人会把这件事理解成“让 AI 自动化更多事情”。这当然没错，但我觉得那是最浅的一层。更深一层的价值，其实是 把组织知识、执行约束和验证方法，从人身上抽出来，沉淀成一套可复用、可审计、可持续调优的系统。 OpenAI 的编码实验本质上是在把工程杠杆放大，OpenAI 的数据代理是在把数据分析门槛往下压，Anthropic 的 auto mode 和 harness 文章则是在降低审查疲劳和把安全决策系统化。
站在企业视角，harness engineering 至少带来四种硬价值。第一是吞吐：人从“每一步亲自做”变成“设计和维护系统缰绳”；第二是可治理：权限、审批、trace、评测和审计终于能进入同一套工作流；第三是组织知识资产化：技能、文档、规则、历史经验不再只躺在老员工脑子里；第四是降低 review toil：不是让人消失，而是把人的注意力留给真正需要判断的地方。需要提醒的是，目前很多漂亮数字主要来自厂商自家案例，因此更应该把它们看成方向信号，而不是拿来直接套 ROI 模板。
十、未来几年，我对这个方向的几个判断
第一，harness 会越来越模板化、平台化。
Thoughtworks 已经明确提出了 harness templates 的概念：企业里常见的服务拓扑、技术栈和工作流，未来很可能会像 service template 一样，配套一整包 guides 和 sensors。到那时，很多组织挑技术栈，甚至会考虑“这个栈有没有成熟 harness 可用”。
第二，harness 会越来越协议化。
MCP 正在把外部能力接入标准化，OpenAI 的 App Server 把 agent 事件流和会话协议化，Agent Skills 则在尝试把组织知识和流程技能标准化。今天我们看到的是一堆点状方案，接下来更可能发生的是：工具、状态、会话、技能、审批、trace 都出现可移植协议。
第三，harness 本身会变成可搜索、可优化、可版本化的对象。
2026 年的几篇 preprint 很值得盯：Natural-Language Agent Harnesses 想把高层 harness 逻辑从 controller code 里外置成可编辑、可执行、可移植的自然语言工件；Meta-Harness 进一步往前走，直接搜索 harness code，在多个任务上找到比手工 baseline 更好的 harness；VeRO 则把 versioned agent snapshots、budget-controlled evaluation 和 structured traces 做成评测 harness，专门服务“agent 优化 agent”。这些都还是很新的研究，其中 NLAH 还明确写着 under review，但方向已经很清楚了：未来被优化的不只是模型参数，还有模型外面的那套 harness。 (arXiv)
第四，harness engineering 很可能会变成一个跨职能新岗位，而不是某个团队的兼职。
因为它天然跨 prompt/context、data engineering、platform engineering、security、QA、observability 和 eval。今天很多公司还是让这些事分散在不同角色上，未来更大的概率是出现专门负责“agent control plane”的团队或岗位。这个判断我没有看到哪家官方直接这么说，但从 OpenAI、Anthropic、Thoughtworks 和研究界同时抬高 harness 重要性的趋势看，我对这个方向相当有把握。
写在最后
如果要用一句话总结我对 harness engineering 的理解，那就是：
Prompt 决定 agent 怎么说，model 决定 agent 大概有多聪明，harness 决定 agent 到底能不能把事靠谱地做完。
所以，别再把 agent 工程只看成“模型调用 + 工具调用”了。真正的分水岭，会越来越体现在这几个地方：上下文是不是系统化管理的，工具是不是被收紧和授权的，状态是不是持久的，验证是不是闭环的，权限是不是继承的，trace 是不是可审计的，漂移是不是持续被清理的。谁先把这套 harness 搭好，谁才真正有机会把 agent 从 demo 推到生产。
