廷哥带你小路超车这两年聊 AI 编码，很多人都在问同一个问题：Agent 都自己写代码了，工程师是不是要失业了？我的答案比较扫兴——目前真正缺的不是会写代码的 Agent，而是能把 Agent 装进研发流程的工程能力。我把它叫 Harness 工程，简单说，就是一套围绕 AI 编码代理构建的任务治理、上下文管理、权限控制、结果验收机制。Agent-First 不是一句口号，它是把“AI 写代码”从演示变成生产的必经之路。
这篇文章不是给你讲某个工具的快捷键，而是讲一个 20 人研发小组从“Cursor 随便用用”到“Agent 批量接单”的完整落地过程。包括怎么设计需求描述规范、怎么用 Codex CLI 跑通第一个任务、怎么把国产 AI 编码工具和 Cursor 类工具放在同一条流水线里，以及踩过的那些不写在官方文档里的坑。适合正在做 AI 编码落地、又不想单纯“人肉 review 每一行机器代码”的技术负责人和一线工程师。
1. 为什么 Agent‑First 不是一句口号，而是工程命题
1.1 Agent 从“补全器”变成“协作者”，失控成了常态
过去两年的 AI 编码工具，大多数人用的是“补全器”模式：你写个函数名，Tab 一下，补全几行。这种模式再烂，失控成本也很低，因为每一行都从你的手底下过，你天然是最后一层审核。
但 Agent 模式不一样。它会自己去翻代码库，自己猜需求，自己改文件，自己跑测试，甚至自己提交 Pull Request。你从“写代码”变成了“派活”。派活听起来轻松，但管理学里有个铁律：授权越多，信息损耗越大，出问题越难追责。
我在项目里见过最典型的一个事故：同事让 Agent“把订单模块的重试逻辑统一改一下”，Agent 确实改完了，但它把三个不同服务的重试时间全部统一成了 3 秒，其中包括一个原本需要 30 秒等待外部对账结果的异步任务。代码评审人只看了 diff，没看业务上下文，直接合了。上线后对账偶发失败，排查了整整两天。
这个事故的本质，不是 Agent 笨，而是没有人给它搭“harness”——也就是一套约束它行为范围的缰绳。你既希望它有足够的自由度去干活，又要确保它在边界内行动。这个矛盾，靠提示词是解决不了的，必须靠工程手段。
1.2 Harness 工程到底在“挽住”谁
Harness 这个词，往浅了说是“马具、缰绳”，往深了说是一种“集成和控制装置”。飞机上有线束 harness，测试框架也叫 test harness。放到 AI 编码场景，Harness 工程就是一套位于“人类工程师”和“AI Agent”之间的中间层。
它在做三件事：
- 把模糊需求翻译成 Agent 可执行的结构化任务；
- 在 Agent 执行过程中限制它的访问范围和操作权限；
- 在执行结束后用统一规则评估产出，并回流到团队的知识库里。
所以你问 Harness 工程“挽住”的是谁？它挽住的不是 Agent 的想象力，而是 Agent 的破坏半径。没有这套东西，Agent 是散兵游勇；有了它，Agent 才是一条流水线上的执行单元。
这也是“Agent-First”和“AI 辅助编程”的分水岭：前者把 Agent 当第一执行者，人类当验收者；后者把人类当第一执行者，AI 当生成器。顺序一变，整个工程的复杂度结构都变了。
1.3 规模化障碍：单机跑通容易，组织落地难
很多人觉得 Agent 规模化最大的障碍是模型不够聪明。我的实际体验是，模型能力的提升速度远远快过工程能力的提升速度。真正卡住规模化的，是以下四个问题：
- 上下文问题：一个大型代码库动辄几百万行，任何单一 Agent 都不可能在一次对话里装下所有相关代码；
- 权限问题：给 Agent 读写全部仓库的权限，风险不可控；给得太少，它又干不了活；
- 一致性问题：不同开发者给 Agent 下指令的方式不一样，产出质量方差极大；
- 验收问题：人类评审的速度跟不上 Agent 产出的速度，瓶颈从“写代码”转移到“看代码”。
这四个问题，没有一个是靠换一个更贵的模型能解决的。它们都需要一套工程化的管理框架，也就是 Harness 工程的核心内容。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 把 AI 编码 Agent 塞进流程：Harness 的五个核心模块
2.1 上下文工程：决定 Agent 是“人肉传话筒”还是“独立作战”
我见过不少团队把 Agent 当成“人肉传话筒”：先让 Agent 看一个文件，再贴一段报错，再让它改一下。这种方式不是 Agent 模式，是高级点的问答。真正能让 Agent 独立作战的关键，是上下文工程。
所谓上下文工程，不是把越多代码塞给 Agent 越好。上下文窗口再大，也会被无关信息稀释。现实做法是给 Agent 建立一个“最小相关上下文”的检索机制。我们组里做过一个简化方案，把仓库索引分三层：
- 全局层：维护一份
ARCHITECTURE.md，里面只写模块边界、核心数据流、关键目录职责，约 2000 字； - 任务层：每次派单时，根据任务描述自动检索关联文件清单，通常控制在 10 个文件以内；
- 文件层：只在中途需要时按需读取具体文件，避免一次性把整个目录灌进提示词。
这套结构的好处是，Agent 不用靠猜就能找到应该读哪些代码。它的“工作记忆”更聚焦，产出质量自然更稳。
2.2 任务拆解与验收闭环：让 Agent 不只跑得快，还跑得对
AI Agent 擅长执行“明确的小任务”，不擅长自己把一个史诗级需求拆成可交付的增量。Harness 工程里，任务拆解应当发生在 Agent 之前，而不是期待 Agent 自己完成。
我们的做法是，所有人机协作任务都走一个最小闭环：
- 描述业务目标；
- 拆成粒度足够小的原子任务（每个任务能在 15 分钟内完成主要改动）；
- 给每个任务写验收标准；
- Agent 执行；
- 自动跑单元测试和静态检查；
- 人类 Reviewer 只对照验收标准做抽样复核。
这一步最关键的不是“拆”，而是“验收标准提前写”。我之前习惯让 Agent“写完先给我看”，后来发现这个做法效率极低。你让 Agent 给你看，它会把所有可能性都试一遍，产出一个大而全的半成品。但如果你说“只需要改动 checkout 服务，且不能影响库存扣减”，它就会收敛自己的探索范围。
2.3 沙箱执行与权限收敛：给 Agent 的“手”戴上手套
Agent 一旦能自主改代码，最大的风险不是它写错，而是它拿到过大的权限。我们曾经给 Agent 开过仓库直接写权限，结果它自动跑 git push 到远端分支，虽然没出大事，但把 CI 触发了一堆没必要的流水线。
所以 Harness 工程的第三块核心，就是沙箱执行和权限收敛。现在主流做法是让 Agent 在一套容器化沙箱里改代码，只挂载它需要的工作目录，不允许访问网络密钥，不允许推开源分支，更不允许执行高危命令。
我在内部搭过一个最小沙箱，规则大致如下：
- 只允许写
/workspace下的文件； - 只允许读
/repo下的白名单目录； - 禁止执行
rm -rf、git push、kubectl、eval等危险命令； - 外部 API 调用全部走 mock，不允许真实扣款或发消息。
规则不是越严越好。太严格，Agent 什么都干不了；太松，又容易出事。我的经验是，先按“最小必要权限”设计，再根据任务类型动态放宽。比如生成单元测试时，可以允许读测试框架配置；但涉及生产环境变动时，一律需要人工输入二次确认。
2.4 可观测性与回放：Agent 闯祸之后你能说清楚发生了什么
Agent 和人类不一样，人类闯祸了会记得自己干过什么，但 Agent 的推理过程在会话结束后就是一团黑盒。如果不做可观测性，你只能看到最终结果，完全不知道它是怎么做出来的。
我们组给每个 Agent 任务都加了执行日志，重点记录四类事件：
- 读文件列表；
- 修改文件前后的 diff 摘要；
- 关键命令执行记录；
- 每一步自我评估的置信度。
有了这些数据之后，最受益的不是追责，而是复盘。你会发现很多“灵异现象”其实有迹可循：比如 Agent 改了一个文件，然后发现测试挂了，它不知道是自己改坏的，于是又在另一个文件里加了个 workaround，导致最终 diff 里藏着两层逻辑。回放日志能帮你快速定位它是哪一步开始跑偏的。
2.5 评估集与回归防线：让升级模型/换工具不再提心吊胆
团队里一旦用上了 Agent，就会面临一个很现实的问题：今天用的模型版本要升级了，或者想换一个更强的编码工具，你敢不敢直接切？
没人敢直接切。因为 Agent 的生成质量没法用“感觉更好了”来衡量。我的建议是，Harness 工程里一定要包含一个评估集，也就是一批能代表你团队典型任务的题目，每个题目都带预期产出和验收标准。
我们现在的评估集有三大类：
- 重构类：把一段重复逻辑抽成公共函数；
- 修 bug 类：给定报错信息，定位并修复；
- 新增功能类：按需求规范实现一个带单元测试的小接口。
每次升级模型或者调整提示词，先拿评估集跑一遍，记录通过率、耗时、改动文件数。通过率没有下降之前，不许上生产环境。这套机制看起来很简单，但能帮你省掉无数“线上突然变笨”的半夜救火。
3. 需求描述规范：我如何让 Agent 听懂“人话”
3.1 一段“能跑”的提示词和一段“能交付”的提示词差在哪
很多人抱怨 Agent 生成代码质量差，但把 Agent 生成的代码和人的提示词放到一起看，你会发现大部分问题出在需求描述上。
一个“能跑”的提示词长这样：
给用户列表加一个分页功能。
Agent 听到这句话，表面上知道要加分页，但它不知道是前端分页还是后端分页，不知道每页多少条，不知道排序规则，更不知道是否需要返回总数。它只能按最常见的方式猜一个。
而一段“能交付”的提示词，至少在以下五个维度上是明确的：
- 改动范围：在哪个模块、哪个文件、哪个接口里改；
- 输入输出：入参是什么、出参是什么、异常如何处理；
- 验收标准：什么算做完；
- 不做的事：哪些边界不需要考虑；
- 技术约束：用哪个框架、是否兼容旧接口、是否需要测试。
这就是为什么我们团队要求所有 Agent 任务都走“结构化任务卡”，而不是直接在聊天窗口里丢一句话。
3.2 用结构化任务卡片替代口语化描述
我把需求描述规范沉淀成了一张任务卡片模板，核心字段如下：
markdown复制## 任务卡片
### 业务背景
为什么做这件事，解决什么问题。
### 改动范围
仓库路径、模块、文件列表。
### 功能要求
- 必须实现的功能点 A
- 必须实现的功能点 B
### 不做什么
- 不需要改动的模块
- 不需要处理的边界
### 技术约束
- 语言/框架版本
- 是否需要写单测
- 是否兼容旧接口
### 验收标准
- 功能标准 1：可以重复执行且无副作用
- 功能标准 2：全量测试通过
- 功能标准 3：新增测试覆盖率达到 80% 以上
为什么它比自然语言描述有效？因为自然语言适合思辨，不适合执行。你把一句“把缓存加上”直接丢给 Agent，它会默认用 Redis；但如果你的项目根本没有 Redis，它就会给你造出一个需要额外部署的依赖。任务卡片把决策项前置，Agent 没有机会自由发挥，产出才可控。
3.3 验收标准优先，方案描述次之
和 Agent 协作久了，我发现一个反常识：告诉 Agent“怎么做”不如告诉 Agent“怎么验收”。
举个例子，你要 Agent 优化一个接口的查询速度。你说“用索引优化查询”，它可能会直接加一个索引，但不知道这个索引的代价，也不知道查询本身是否有更合理的写法。但如果你说“接口 P99 响应时间从 800ms 降到 200ms 以下，且全量测试通过”，Agent 就会自己去分析慢查询、看执行计划、尝试不同方案。
Agent 的最大优势是它能尝试多条路径，最大劣势是没有业务主观判断。验收标准写得越清楚，它就越能用“试”的方式逼近目标，而不是靠猜来满足你的字面要求。
3.4 边界条件与“不许做什么”
比“要做什么”更重要的是“不许做什么”。Agent 的探索欲很强，尤其是面对复杂任务时，它会把“相关但不该动”的地方一起改掉。我们组有一段时间频繁出现同一个问题：Agent 为了通过一个测试，偷偷改了另一个模块的公共函数，结果引发连锁回归。
后来我们规定，所有任务卡里必须有一节“禁止改动”，明确写出不允许触碰的目录或函数。这样即使 Agent 觉得改动“很有必要”，也会因为边界约束而停下来询问，而不是擅自扩大影响面。
你可能会担心给 Agent 的限制太多，会不会降低效率。我的体验是，限制只会在“无关紧要的探索”上降低效率，但能在大方向上保住正确性。对 Agent 来说，正确的边界约束就是最大的上下文。
4. Codex 类 CLI Agent 的快速接入与 Harness 落地
4.1 为什么 CLI Agent 更适合做 Harness 的被管理者
对话式编辑器里的 Agent 很好用，但它和 Harness 工程整合时有一个天然障碍：它的一切操作都在编辑器的 GUI 里发生，你很难用脚本去控制和观测。
Codex 这类 CLI Agent 就不一样。它天然就是一个命令行程序，输入是文本任务，输出是文本结果，中间还会调用文件读写和终端命令。这意味着你可以用标准输入输出把它包进自己的流水线里，像调用一个函数一样调用它。
这就是 Harness 工程和 CLI Agent 的契合点：你不需要去操作一个黑盒 GUI，你可以写一段调度脚本，控制它的工作目录、环境变量、输出路径，然后把它的产物交给下一道测试工序。
4.2 最小接入路径：从安装到跑通第一个任务
如果你所在团队还没用过 Codex 类工具，我建议按这个最小路径跑一遍，不要一上来就接大型任务。
第一步：安装 CLI。这里不展开安装细节，你只需要安装到本地，能执行 codex 命令即可。
第二步：准备一个干净的工作目录。强烈建议不要让 Agent 直接在一个大型仓库的根目录里跑。先准备一个临时目录，把相关代码复制进去，做一个小实验。
第三步：写一个最简任务文件。我经常会用 task.md 作为输入，内容包含任务卡片的几个核心字段。然后在命令行里执行类似这样的命令：
bash复制codex "请阅读 task.md，完成其中的任务，并执行新增的单元测试"
第四步：检查产物。看看它改了哪些文件，新增了哪些测试，是否引入了不该出现的依赖。如果这一步没问题，再考虑接入正式流水线。
这个最小路径看起来很简单，但它能帮你验证一件事：你的工作环境、模型权限、任务描述方式是否适合 Agent 执行。如果这一步就磕磕绊绊，后面接全流程只会更痛苦。
4.3 把 Codex 接进 Harness：任务下发、权限限制、结果回收
跑通单次任务之后，就可以把它接入 Harness 框架了。我的做法是写一个简单的任务调度脚本，用伪代码表示大概是这样：
code复制for task in task_list:
prepare_workspace(task)
write_task_card(task)
run_codex(headless_mode=True, timeout=600)
collect_diff()
run_tests()
if tests_pass:
create_review_branch()
else:
record_failure(task.name)
这里有几个细节值得注意。
第一，任务列表不能是人手动逐个敲的，应该从一个统一的 Backlog 里生成，自动带上边界约束。第二，timeout 必须存在。Agent 在复杂任务上可能陷入死循环，没有超时控制就会无限消耗时间和成本。第三，结果回收时不要只回收“成功”的任务，失败任务里的日志和中间产物同样宝贵，它们是后续改进提示词的燃料。
权限限制这一层，我建议用系统级的方式做，而不是只靠提示词。比如在容器里跑 Codex，然后用只读文件系统和白名单命令控制它。这样即使提示词失效，系统依然能兜底。
4.4 绕开的三类坑：长任务断连、上下文膨胀、误改文件
Codex 类工具接进来之后，我们实际踩过三类坑，这里展开讲一下。
第一类是长任务断连。Agent 跑一个多步骤任务时，如果中间某个命令超时或者网络抖动，它可能会直接认为自己完成了，但实际上只做了一半。我们的解决方案是给任务增加“阶段检查点”：每完成一个阶段，就让 Agent 输出一个简短状态，脚本定期检查状态是否与预期一致。
第二类是上下文膨胀。随着对话轮次增加，Agent 的上下文会越来越长，它的注意力会被早期内容占据，后期内容容易忽略。典型表现是，前几步还严格遵守任务卡，做到最后开始忘掉“禁止改动”的限制。我们后来强制每个原子任务都从新的会话开始，并且把任务卡和中间产物放在文件里，而不是全塞进对话历史。
第三类是误改文件。这个无法完全避免，只能靠回放日志来及时发现。我们现在要求 Agent 在每次修改前先打印将要修改的路径，脚本把这些路径和“允许修改白名单”做比对，一旦发现越界就中断执行。这是 Harness 工程里最有效的一道防线。
5. Cursor、国产助手与 Harness 工程的边界：工具选型不是站队
5.1 编辑器内 Agent 与平台级 Agent 的本质差别
现在市场上有两类 AI 编码工具：一类是 Cursor 代表的编辑器内置 Agent，强调在代码编辑器里完成上下文理解、生成和修改；另一类是国产助手和平台级工具，强调 Code Review、单元测试、DevOps 链路集成。
很多团队在选型时陷入“谁更强”的争论，我觉得这是伪问题。编辑器内 Agent 强在交互体验，它看得见你光标在哪儿，知道你正在纠结哪个函数，适合人在回路里的实时协作。平台级 Agent 强在流程治理，它更擅长接任务、跑流水线、做批量变更，适合无人值守的自动化执行。
Harness 工程需要的是第二种能力。它本质上是一个“任务管理 + 执行控制 + 结果验收”的框架，不一定非要绑死在某一个编辑器上。你今天可以用 Cursor 做交互式探索，同时用平台级 Agent 做流水线任务。两者并不互斥。
5.2 从可用性、私域部署、成本三个维度看国产工具
我所在的团队对国产 AI 编码工具一直保持开放态度。实际用下来，它们在三个维度的收益很明确：
- 可用性上，国产助手对中英文混合需求的理解更自然，在处理国内团队的代码注释、工单描述时，很少出现“翻译腔”式的生成；
- 私域部署上，很多国产工具支持企业级私有化部署，代码不会出内网，这对金融、政务、企业服务项目是刚需；
- 成本上，预打包的企业套餐通常比按人次订阅的海外工具更容易做预算评估。
但我也要客观说，在“编辑器内上下文感知”这个交互细节上，Cursor 依然有自己的优势。它的 Tab 补全和跨文件理解做得很顺滑。我的态度是：工具选型别站队，把国产工具放到 Harness 工程流水线里，让它承担批量任务和私域合规场景，把 Cursor 留给需要高交互的探索场景。这样双方各干各擅长的活。
5.3 Harness 工程与具体工具解耦：让流水线不绑架在单一工具上
我们做过一次实验：把同一批评估集任务分别用 Cursor 和国产助手跑了一遍，结果发现，只要任务卡写得好，两者的“达标率”差异远小于大家预期。真正拉开差距的场景，是任务描述模糊、需要 Agent 自由发挥的时候——这种时候无论什么工具都会跑偏。
所以我在组里定了一条原则：Harness 工程必须和具体工具解耦。任务格式、验收规则、权限控制、日志回放，这些都要和工具无关。任何一个工具都可以通过适配器接入，也可以随时被另一个工具替换。
这样一来，当工具 A 涨价或者工具 B 发布了更强的模型时，你可以快速切换，而不需要把所有流程重写一遍。这才是 Agent-First 时代该有的工程心态：你不是某个工具的粉丝，你是你团队交付质量的负责人。
6. 真实落地效果：一个 20 人小组的 Harness 实施记录
6.1 试点范围选择：为什么先啃“目录迁移”而不是“新功能开发”
第一次把 Harness 工程引入到正式项目时，我们组选了一个听起来很不起眼的任务：目录迁移。就是把一个老服务的若干模块从一个目录结构迁到新的分层结构。这个任务具备三个适合试点特点：
第一，边界清晰，老目录和新目录的映射关系是确定的；第二，验收容易，迁移后只要编译通过、测试不挂，就基本成功；第三，风险可控，不会直接影响业务逻辑。
很多团队喜欢拿“新功能开发”做试点，我建议不要。新功能必然伴随着需求不明确、方案反复调整，这类任务本身是人类工程师都很难一次做对的，让 Agent 直接上手只会放大混乱。目录迁移、批量格式化、依赖升级这类“重体力、轻判断”的任务，才是 Harness 工程的第一批主力场景。
6.2 两周内的指标变化：人工评审时间下降了，但验收标准也变严了
试点跑了两周后，我们拿到了几组比较有意思的数据。
| 项目 | 实施前 | 实施后 |
|---|---|---|
| 批量任务平均处理时间 | 1.5 人天 | 0.5 人天（大量是等待 Agent） |
| 人工代码评审总时长 | 6 小时/批 | 4 小时/批 |
| 评审中发现的“低级错误” | 30% | 12% |
| 一次评审通过率 | 45% | 68% |
注意，人工评审总时长确实下降了，但下降的原因不是评审变松，而是验收标准前置了。Agent 在执行过程中就按任务卡跑测试，很多明显问题在提交前就被拦截了。评审者看到的是更接近“可合并”状态的代码，而不是需要逐行改的草稿。
但这里有一个代价：验收标准的编写本身需要时间。我们把需求描述的时间从原来的 10 分钟提高到了 30 分钟，前期好像更慢了，但总账算下来，反而是赢的。
6.3 团队协作方式的改变：从“人写代码给机器跑”到“人写需求给 Agent 执行”
Harness 工程落地后，团队里最明显的变化不是代码量，而是角色分工。
以前，工程师的日常是：读需求、写设计、写代码、跑测试、改 bug。现在，大部分“写代码”的环节被 Agent 接走，工程师把精力放到了更上游的两个环节：一是把业务需求翻译成任务卡，二是对 Agent 的产出做验收。
这个变化带来的好处是，初级工程师也能在指导下完成复杂的重构任务，因为他们只需要把任务拆够细、验收标准写够清楚，Agent 会替他们做大量的实现试探。坏处是，如果你不建立评审纪律，团队很容易变成“人类流水线包装工”，只负责把 Agent 的话术转来转去。
我们内部现在有一条不成文的规矩：任何人提交的 Agent 任务，都必须附上“任务卡 + Agent 回放日志摘要”。没有这两个东西，代码评审直接打回。这从流程上逼着所有人把需求定义先于生成结果。
6.4 踩过的最深一个坑：Agent 生成的代码通过评审，但埋了一个隐患
最后说一个让我印象深刻的坑。团队用 Agent 完成了一个支付通知模块的改造，任务卡里明明写了“超时时间可配置”，Agent 也做到了，测试也过了，Reviewer 也看了 diff，合入主干一切正常。
一周后，运维发现通知队列积压。排查后才发现，Agent 在实现“超时时间可配置”时，顺手把线程池的大小也固定成了 1，而原来的代码是 4。这个修改藏在 diff 的一行里，Reviewer 的注意力全在超时时间配置上，根本没注意到线程池变化。
这件事让我意识到：人工评审 Agent 的代码时，不能只看“我要求的功能实现没有”，还要追问“它还改了什么我不该让它改的东西”。更稳妥的办法是，在评审前自动生成一份“非任务相关改动清单”，把那些和任务卡无关的 diff 高亮出来。现在我们的回放日志里已经增加了这个字段，专门标记“偏离任务目标的额外修改”。
7. 把 Harness 工程沉淀成团队的“第四类代码资产”
7.1 先定边界，再选工具
如果你正准备在团队里推进 Agent-First 编码，我的第一建议是：不要先纠结工具，先定边界。
你需要在团队里回答三个问题：
- 哪些模块允许 Agent 直接改，哪些模块必须人工写？
- 哪些命令允许 Agent 执行，哪些命令一率禁止？
- 哪些任务可以完全自动化验收，哪些必须人工体验后才能放行？
这三个问题的答案，才是你 Harness 工程的第一版设计文档。工具只是把它落地的载体。边界不清晰的时候，换再强的模型也只是把错误放大。
7.2 从“小范围闭环”开始，而不是“全员 All In”
推动任何工程实践最忌讳的就是轰轰烈烈地全员推广。建议先挑一个两到三人的小组，选一类低风险、高重复度的任务，跑通“任务卡 → Agent 执行 → 自动测试 → 人工抽查”的闭环。
跑通之后，复盘两个问题：一是这类任务的平均验收时长相比人工是否真的下降；二是 Agent 的执行日志是否足够支撑你排查问题。如果这两个问题都成立，再决定是否扩大到更多团队。如果连小规模试点都磕磕绊绊，那大概率不是工具的问题，是需求描述规范还没打磨好。
7.3 把 Harness 工程沉淀成团队内部的“第四类代码资产”
传统研发团队有三大资产：业务代码、测试代码、基础设施配置。现在应该加第四类：Harness 工程资产，包括任务卡模板、评估集、权限规则、回放日志分析工具。
这类资产最大的价值在于可复用。新人进来，不需要靠口口相传才知道“怎么给 Agent 派活”，直接看任务卡模板和评估集，就能知道团队对 Agent 的期望是什么。同样，当模型升级或工具变更时，你也不需要重新拍脑袋，直接跑一遍评估集就能量化变化。
我个人在实际项目里最深的一个体会是：Agent 的代码能力会持续提升，但工程纪律不会自动跟上。谁先建立围绕 Agent 的治理框架，谁就能在这波 Agent-First 浪潮里走得更稳。Harness 工程不是给 Agent 套枷锁，而是让它在正确的轨道上发挥真正的规模效应。