“提示词工程师可能要被时代抛弃了”这句话过去一年我在业内已经听腻了但今年越来越多团队真的开始把“写提示词”这件事降级成日常杂务而把重心放到一个更工程化的词上——Harness Engineering。近几个月我给几个智能体项目做技术顾问明显感觉到一个拐点当上下文窗口从几千 token 卷到百万 token 后Context Engineering 带来的边际收益越来越低真正决定项目上限的反而是模型外面那层“壳”——工具权限、执行沙箱、反馈闭环、可观测性。OpenAI 开源 Codex harness、Anthropic 在 Claude Code 里沉淀 agentic skill 进化机制本质上都在押注这个方向。这篇文章我想把这两件事串起来聊透Context Engineering 碰到了什么瓶颈Harness Engineering 到底在解决什么问题以及普通开发团队怎么把思考方式迁移过去。1. Context Engineering 的边界为什么上下文调优已经不够用了1.1 上下文红利期的真实天花板过去两年Context Engineering 是一个很性感的词。模型刚火那阵子所有人都在研究怎么把资料塞进窗口、怎么压缩检索结果、怎么写 system prompt 防止模型跑偏。窗口从 4k 涨到 16k、200k再到 1M很多人觉得“只要上下文给得够多模型就足够聪明”。这个思路在单轮问答、摘要生成、知识库问答上确实有效也是一众 RAG 应用能够落地的根本原因。但窗口变大并不等于“有效上下文”变大。我在实际项目里测过当把超过一定量的检索结果直接拼进 prompt 时模型对中段信息的利用程度会明显下降甚至出现“上下文污染”——一条噪音信息就可能把后面所有判断带偏。这时候大家开始做 rerank、做压缩、做上下文选择器本质上是在帮模型做注意力筛选。这套方法论没有错但它的优化对象是“模型读取输入的能力”而不是“模型接下来要执行的任务本身”。一旦任务变成多步的、需要反复调用外部工具的智能体任务瓶颈就不在输入侧了。比如一个客服工单处理智能体它要先查用户历史、再查订单状态、再判断退款策略、最后生成邮件回复。中间任何一步的结果都会影响后面的输入你无法提前把所有情况都塞进 prompt因为你根本预测不到它会查到什么。此时继续优化上下文工程都是在打补丁解决不了系统级的问题。1.2 失败模式转移从答错到失控上下文工程时代最常见的失败是“答错”给的事实不够、指令有歧义、格式不符合预期。这些问题可以在输出端直接看到反馈链路短调一版 prompt 马上就能验证。Harness 时代要面对的是另一种失败我称之为“失控”。模型拿到了工具调用权可以访问文件系统、可以执行代码、可以调外部 API它可能方向是对的但调用链中有一环出了偏差整个任务就跑偏了。举个我真实遇到的例子一个内部数据分析智能体最初是纯 prompt 实现效果还不错。后来让它能直接连接数据库并执行 SQL模型自己拆解问题、自己生成 SQL、自己读结果。低风险查询没问题但有一次它为了回答“某个指标为什么下降”生成了一条涉及全量用户表的聚合 SQL直接让数据库负载飙升。这个问题非常典型不是 prompt 写得不清楚而是没有一个执行层面的约束结构来兜底。Context Engineering 关心的是“把意图说清楚”但在模型真正拥有工具和行动能力之后必须有一个东西关心“允许它做什么、每一步如何被记录、错了如何恢复”这就是 Harness Engineering 的职责。1.3 我的判断Context Engineering 没有过时而是降级为子模块直说结论Context Engineering 不会过时但它的地位会从“解决方案本身”降为“方案里的一个环节”。Harness 是更大的系统上下文管理在其中承担的意义相当于汽车里的供油系统。油路当然重要但你不能靠调油路参数让汽车自己学会刹车、转向、看仪表盘。对应到智能体场景里Harness 要解决的是执行环境、工具注册、权限边界、沙箱隔离、日志回放、评估反馈、技能沉淀。上下文怎么组装、怎么压缩只是执行链路中的一个步骤。所以我的建议是不要把上下文工程和 Harness 工程对立起来应该重新安排精力配比。如果你还在做纯问答类应用Context Engineering 仍然是主战场。但只要你决定让模型接触工具、执行多步操作就一定要把主要精力转移到 Harness 设计上否则早晚会被“失控问题”吞掉。2. Harness Engineering 到底在做什么一次本质层面的拆解2.1 一个直观的比喻模型是引擎Harness 是整车Harness 这个词我最早接触是在测试领域叫 test harness指的是围绕被测对象搭建的一整套执行、监控、夹具系统。后来在机器人、编译器和 SDK 开发里也常见包的是“设备与主控之间的连接控制层”。放到大模型场景里它的定位可以这样理解模型是一个发动机马力再大你不能直接坐发动机上出门。你得有车身、方向盘、刹车、油表、导航、路况感知这些东西合起来才是可以安全开上路的车。对应 AI 应用模型只是引擎Harness 是车架——它负责把模型接到真实环境里同时又给它套上约束和反馈。一个标准 Harness 至少包含这几层执行环境模型能在哪个沙箱里运行能访问哪些资源代码执行如何隔离。工具层外部工具的注册表、参数 schema、调用鉴权模型不是想调就能调。控制层步骤限制、token 限制、人工审批点、中止条件。可观测层每一步的输入输出、工具调用记录、成本统计。反馈层任务结果评估、错误归因、技能沉淀机制。这五个层里Context Engineering 只参与第一层的输入组装剩下的都是它管不到的。这也是为什么模型已经很强但很多 agent 产品体验仍然稀烂——不是引擎不行是车架没搭好。2.2 Harness 与相关概念的边界很多读者会把 Harness Engineering 和 Agent Framework、RAG 搞混我做一个尽量清晰的边界划分概念核心关注典型产物局限Context Engineering优化模型输入prompt 模板、上下文压缩、rerank只管输入不管执行RAG知识接入向量库、检索链路、混合检索只解决知识获取不解决行为控制Agent Framework编排与调度LangGraph、AutoGen 等提供了脚手架但“管住行为”要靠使用者二次开发Harness Engineering可控执行闭环沙箱、工具权限、日志回放、评测反馈、技能进化需要整体设计投入成本高可能有人会问Agent Framework 不已经在做这块了吗我的理解是Framework 解决的是“怎么把多个调用串起来”的编排问题而 Harness 解决的是“确保这个执行过程可控可信”的工程问题。框架给的是轮子Harness 给的是一整套包含刹车和保险带的驾驶舱。你可以用 LangGraph 写一个复杂工作流但如果没做工具权限控制、没做沙箱、没做过程日志回放它依然不是一个合格的 Harness。2.3 四条关键设计原则约束、可观测、闭环进化、最小权限过去半年我做了几个项目的 Harness 化改造沉淀下来四条不变原则约束优先于能力。设计 Harness 时先列“绝对不能做什么”再列“允许做什么”。白名单永远优于黑名单。给模型开放的每一项能力都必须有清晰的边界和触发条件。一切动作可回溯。模型调了什么工具、传了什么参数、拿到了什么结果、基于什么原因做了下一步判断全部要记录。没有可观测性就没有调试能力更没有信任可言。形成进化闭环。Harness 不是为了跑完一次任务而是要让每次任务的经验沉淀下来。这直接关系到后面要讲的 meta context engineering via agentic skill evolution——执行完任务后把方法固化为技能下次直接复用。最小权限动态授予。初始只给读权限中间发现确实需要写操作再按特定路径、特定时间窗临时授权。权限越大模型能犯的错越大。这四条听着像安全设计但其实是产品体验设计——绝大多数 agent 翻车事故追根到底都是某条原则被违反了。3. OpenAI 和 Anthropic 的产品为什么都指向同一个方向3.1 OpenAI Codex从代码补全到自带执行环境的“智能体宿主”如果你只用过 GitHub Copilot 时代的 Codex可能理解不了为什么 OpenAI 要把 Codex 重新包装成一个终端里的智能体产品。新版 Codex 已经不再是一个“生成代码的模型”而是你终端里的 AI 工程师它有自己的 CLI、运行环境、沙箱机制可以读取仓库、执行测试、提交 PR。OpenAI 还直接把 Codex harness 开源出来这个动作很值得琢磨。“harness”这个词是官方明确使用的它实际上就包括容器化沙箱、工具定义、会话管理、用户审批流程、安全检查机制。也就是说OpenAI 在对外传递一个信号——你要的不是 API 调用而是一个能安全执行任务的完整“工作台”。3.2 Anthropic Claude Code把终端变成可控工作台Anthropic 的 Claude Code 走的是另一条但方向完全一致的路线。它同样在终端里构建了长周期任务执行环境支持多文件修改、命令执行、测试反馈循环。Claude Code 最有价值的地方不只是模型能力而是 Anthropic 把很多“如何在终端里安全地让模型行动”的工程经验内置进去了。比如 subagent 拆分、任务状态的持久化、用户审阅点、以及围绕“记录技能并复用”的机制。过去只有工程师会用终端而 Claude Code 把终端变成了智能体的工作台。这背后正是 Harness 工程在起支撑作用——模型、工具、权限、进程、反馈全都被编排在一个可控制的环境里。3.3 Meta Context Engineering via Agentic Skill Evolution新一轮热词的工程含义最近这个说法开始在圈里流传meta context engineering via agentic skill evolution。直接从字面翻译是靠智能体技能进化来做的元上下文工程。这个概念看着绕落到工程上其实很具体。传统 Context Engineering 是人在每次对话前手工组装上下文而 meta context engineering 是让模型自己维护一套上下文构建机制。做法通常是这样代理执行完一个较为成功的任务后Harness 会从中抽取关键模式——这套任务是怎么拆解的、用了哪几个工具、工具的调用参数长什么样、遇到异常怎么处理——把模式固化成一个“技能”存进技能库。下一次遇到同类任务代理直接调用技能库里的模板来构建上下文而不是从零重新思考。这个机制的第一个关键词是“进化”技能会随着任务执行不断更新迭代。执行得好的技能会留下来失败的工具链会被修正。第二个关键词是“元”模型管理的不再是具体事实而是“如何组织上下文”的方法。这不是论文里的概念在最新一代开发工具里已经能看到雏形。Claude Code 的技能skills机制、Codex 对任务模板的复用都是在往这个方向走。而技能库的维护、版本化、冲突消解、安全审查又回到 Harness Engineering 的工作范畴——没有 Harness 做承载技能进化只会变成混乱的配置文件堆积。3.4 开源 Harness 背后双方在抢什么OpenAI 和 Anthropic 几乎同时把底层 Harness 开源或半开源肯定不是做慈善。他们都明白未来的竞争力不止在模型还在开发者构建智能体的默认工作流。谁的 harness 生态先跑起来谁的模型调用频率就更高、反馈数据就更丰富、生态锁定就更深。对开发者来说这个局面是好事。以前你要自建一整套 agent 执行框架现在可以直接站在两个大厂开源 harness 的基础上改。但也要清醒公开的 harness 只是地基真正让你的智能体可靠、可控、有价值的仍然是你根据业务场景做的约束和设计。4. 落地从“写提示词”切换到“设计 Harness”的实操路径4.1 先判断你的任务需不需要 Harness 化不是所有 AI 应用都需要上 Harness强行上只会增加成本和复杂度。我一般用四个标准判断任务是否多步如果只调一次模型就完成任务那属于 Context Engineering 范畴。是否涉及外部工具与副作用读文件、写文件、调 API、执行命令只要有其中之一就需要执行控制。是否允许模型在一定范围内自主决策如果是纯转译式任务比如“把这段文本翻译成英文”不需要 Harness。如果任务存在路径分叉需要 Harness。是否要长期复用和持续优化一次性 demo 不用考虑反复运行的工作流必须要。四步全中的放心上 Harness。只中一两项的可以轻量引入部分机制不必全套。4.2 最小可行 Harness 清单六件事如果你不想直接搬大厂那种几万行代码的框架可以先做一个最简版本。我把核心组件收敛成六件事一个隔离执行环境。可以是 Docker 容器、云函数沙箱或者至少是独立的 Python 虚拟环境。目的是让模型的动作错误不会波及宿主。一个工具注册表。所有外部函数的 JSON Schema、鉴权信息、调用限制提前登记模型只能调用注册过的工具。权限策略。针对每一步操作设置白名单、文件路径范围、接口调用频率支持临时授权。结构化日志。每个模型调用、工具调用、关键决策都输出结构化 JSON 日志便于回放和归因。任务级评测集。不只是测“回复好不好”要测“任务有没有正确完成”以及“过程有没有违规操作”。技能/经验库。每轮任务结束后由人机协同提取可复用的方法片段存入独立目录并版本化。这个清单做出来你的 agent 已经比大多数 demo 可靠一个数量级。后面再根据业务复杂度往上加东西。4.3 利用现成工具不要从零造车轮很多团队问我“要不要用 LangGraph 自己搭一套 Harness”我的建议永远是先看开源方案。当前阶段可以直接借鉴的有这么几个OpenAI 官方开源的 Codex harness适合代码任务结构清晰沙箱和容器隔离已经内置。Anthropic Claude Code 的 skills 机制适合参考技能定义与复用方式它展示了一条“任务完成后沉淀技能”的实用路径。通用编排层用 LangGraph 或 Temporal处理复杂确定性任务和人工审批流。选型时要记住一个原则Harness 的第一目标是可控不是炫技。优先选社区活跃、事件日志完善、能方便接入自己评测体系的项目。有时候现成框架的约束不够宁可在上面加一层自定义策略引擎也不要彻底自研。4.4 一个真实场景的改造示例客服摘要智能体举一个我上个月帮客户改造的案例或许更容易理解。原本的系统是一个“客服对话摘要”工具调用大模型输入历史对话文本输出结构化摘要。上线后发现两个问题其一摘要很容易遗漏售后问题的处理结果其二模型偶尔会把用户的情绪化表述当成事实导致摘要失真。我们做了一次 Harness 化改造改造前是一个 prompt 调用改造后变成一个小型智能体系统。第一步模型不再直接写最终摘要而是先通过只读工具查询订单状态和工单记录用结构化数据校验对话里提到的信息。第二步Harness 规定模型必须先输出“事实抽取列表”再由另一个校验模型比对原文进行一致性检查不一致的会被打回重抽。第三步校验通过的摘要会被记录到日志每周跑一次评估集自动标注新增失败样本。第四步凡是成功处理过的对话类型agent 会把“订单退货类任务的摘要模板”固化到技能库下次启动直接从模板构建上下文。结果摘要准确率从 78% 提到 94%。关键不是模型换了或 prompt 精调了而是通过在 Harness 层加工具校验、拆步骤、搭评测把一个不可控的单次调用变成了可监督的流程。5. 避坑与经验我在 Harness 化改造中踩过的坑5.1 别把工具调用权限开成“万能通行证”第一次给智能体接数据库时我图省事把数据库读写权限全部交给了模型结果出现了前面说的全表聚合查询事故。之后我形成了习惯初始只给只读权限并且强制查询必须带 LIMIT一旦模型要执行修改操作必须走审批流程。权限设计宁可繁琐不可宽松。5.2 沙箱不是部署完就完事要能复现我们踩的另一个坑是沙箱环境与生产环境不一致。智能体在沙箱里调试得很好一到生产环境就各种文件路径、依赖版本问题。后来用 Dockerfile 锁定环境、日志里加入环境指纹才逐渐稳定。沙箱的意义不只是隔离还要保证“模型看到的环境”和“我们控制的环境”完全一致否则一切测试都失真。5.3 评测粒度过程比结果更重要一开始我们只评测最终结果发现很多任务最终输出正确但是中间调用了本不该调用的工具或者遍历了大量数据。这类低效路径在结果评测里完全看不出来却会造成真实成本失控。后来我们把“过程违例数”“工具调用效率”“危险操作拦截率”也纳入评测指标模型的行为才逐渐收敛到合理路径上。5.4 维护“技能库”不等于堆文档刚开始我们让 agent 自己沉淀技能跑了一周技能库里堆了几百个文档大部分是重复和过时的。后面改用半自动流程agent 提出技能候选人来审核合并技能必须经过至少 3 次成功任务验证才能上线技能库本身也要做定期淘汰。技能进化的关键不是“全自动”而是“人机协作闭环”。5.5 关于“OpenAI/Anthropic 齐发力”的一个冷静判断很多文章喜欢把这次的开源/harness 之争渲染成“神仙打架”但落到工程实践上我更建议大家按自己的场景拆解需求。大厂开源的东西解决的是通用路径你业务里的长尾场景、领域规范、安全边界终究要自己设计。Harness 工程不是一个“装了就能用”的产品而是一套需要持续投入的设计方法。6. 接下来半年值得关注的变化6.1 技能演化的标准化尝试meta context engineering via agentic skill evolution这个概念正在从极客圈往外扩散但目前的实现还很零散。我判断未来半年会看到更多关于技能格式、技能共享协议、技能版本管理的标准化尝试。到时候不同 agent 之间互认技能包会比现在容易很多。早期参与这些规范的团队有可能会形成事实标准。6.2 多智能体之间的 Harness 互操作现在的多智能体系统各写各的 harness互相之间不认账。下一阶段可能出现共享工具注册中心、统一权限审计网关、跨 agent 的安全令牌体系。对企业开发者来说提前把日志格式、工具 schema 定义得规范化未来做互操作会省很多事。6.3 对个人开发者与团队的建议把“提示词工程师”的思维升级成“智能体系统工程师”。prompt 依然要写但那只是系统设计的一个环节。从最小 Harness 清单开始不要一开始就追求大而全。先把日志、权限、评测做起来再谈技能进化。保持对模型能力上线后“边界条件”的关注模型更新可能让原来的约束失效Harness 也需要定期回归测试。7. 最后再分享一个小技巧我最近做智能体项目时养成了一个习惯每次上线新任务第一件事不是调 prompt而是先画一张极简的“动作谱系图”——模型在完成这个任务时可能涉及哪些动作、每个动作需要什么权限、哪个动作是最危险的、哪个动作是可以直接砍掉的。这张图画完prompt 怎么写、工具怎么开、评测怎么设几乎都是顺理成章的。这个习惯让我少踩了很多坑。Context Engineering 解决的是“让模型更聪明地理解任务”而 Harness Engineering 解决的永远是那个更朴素的问题让模型在真正做事情的时候过程和结果都处于我们可以掌控的范围之内。大厂已经在往这个方向投入我们这些一线做应用的人最应该做的不是追逐术语而是把注意力真正放到“可控执行”这四个字上。
