个人Harness总结AI相关其他概念AI基础学习-基础概念汇总文章目录一、基本概念---到底什么是Harness Engineering驾驭工程1. Harness Engineering诞生背景---Agent长程任务痛点与AI 工程范式三次跃迁2. Harness Engineering正式提出---围绕Agent运行优化系统工程实践3. Harness Engineering核心逻辑---给Agent搭一套工业化生产管控体系二、典型案例---Harness Engineering业界典型落地案例案例 1HashiCorp 官方 Harness Engineering 落地实践---术语发起方案例 2LangChain 生产级 Agent Harness 体系落地---AI Agent 领域头部案例 3OpenAI 官方 GPT-4o 代码解释器 Harness 体系---大模型原厂实践三、详细案例分析---claude code真正的Agent Harness工程1. 上下文管控---知识按需加载、子代理上下文隔离、三层上下文压缩2. 可配置执行能力---工具热注册、Skill 文件系统、插件与扩展架构3. 任务分解调度---TodoWritenag、子任务委托、DAG任务图、后台异步执行、多Agent团队4. 硬约束与闭环反馈---路径沙箱、操作审批门控、Shutdown 握手5. 熵增治理---对话归档、任务状态持久化、团队通信记录、生命周期事件流、项目知识沉淀四、实践指南---给团队负责人搭建Harness的行动手册1. 动态上下文治理---统一团队的知识入口防止各说各话2. 构建配置执行能力---统一工具链防止各装各的3. 有序任务调度---统一需求的拆解方式防止理解偏差层层放大4. 架构硬约束与闭环反馈---自动化门禁防止人忘了审查5. 系统熵增治理---用 Agent 清扫 Agent 的产出防止坏模式指数级扩散五、总结一、基本概念—到底什么是Harness Engineering驾驭工程1. Harness Engineering诞生背景—Agent长程任务痛点与AI 工程范式三次跃迁随着Agent能力越来越强各种失效模式逐渐显现。真正决定它能不能稳定交付、能不能连续跑几个小时不失控、能不能在关键时刻被拉回正轨的反而不是模型本身而是你有没有给它一套工程化管理的逻辑也就是我们讨论的Harness Engineering。常见 Agent 失效模式序号Agent 失效模式具体表现1试图一步到位单个会话完成所有功能耗尽上下文窗口留下无文档半成品后续会话需反复猜测前期操作2过早宣布胜利项目后期看到部分进展即宣布任务完成忽略未实现的大量功能3过早标记功能完成写完代码即标记完成未做端到端测试仅单元测试通过不代表功能真正可用4幻觉频发且无法闭环缺乏校验机制生成错误信息代码且无法复盘修复重复出现同类错误5权限与边界失控无约束机制易出现越权操作、高危命令执行存在安全风险Harness出现之前AI 研发落地经历了两代范式都无法解决生产级场景的核心痛点范式代际核心能力无法解决的致命痛点研发团队的真实体感第一代提示工程优化单次 Prompt 话术提升单次推理效果只能管单次对话管不了长周期、多轮次任务AI 换个场景就犯错重复踩同一个坑提示词改了无数遍AI 还是会写 bug、出幻觉、偏离需求第二代上下文工程 / RAG给 AI 喂知识、管记忆让 AI 知道该做什么只能解决AI 不知道的问题解决不了AI 知道但做不到、做不对的问题无法管控执行流程、约束行为边界AI 拿着完整的架构文档还是写出不符合规范的代码文档和代码两张皮第三代Harness Engineering给 AI 建全链路管控体系让 AI做对事、不重复犯错彻底解决前两代的核心瓶颈收敛 AI 的不确定性实现生产级稳定落地每踩一个坑就彻底堵死这个坑AI 越用越稳方案开发越做越快2. Harness Engineering正式提出—围绕Agent运行优化系统工程实践2026 年 2 月HashiCorp 联合创始人 Mitchell Hashimoto 在其博客 My AI Adoption Journey 中首次正式提出该术语随后 OpenAIHarness engineering: leveraging Codex in an agent-first world、LangChainThe Anatomy of an Agent Harness、AnthropicEffective harnesses for long-running agents等头部厂商陆续发布各自的 Harness Engineering 实践文章形成全行业共识。Harness Engineering是围绕 AI Agent设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践它不优化模型本身而是优化模型运行的环境。由此更新Agent的定义Agent Model大模型算力核心 Harness驾驭体系工程化核心harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.—— Mitchell Hashimoto每当你发现 Agent 犯了一个错误你就花时间设计一套系统性解决方案使 Agent 永远不再犯同样的错误这就是 Harness Engineering 的核心本质。3. Harness Engineering核心逻辑—给Agent搭一套工业化生产管控体系Harness 就是围绕 AI 模型搭建的一整套工作环境和工作流程。你给 AI 写的项目规则文件、配置的各种工具、安排的任务拆分和执行顺序、设计的测试检查流程这些统统都算 Harness。管边界明确AI能做什么、绝对不能做什么管流程强制AI按标准步骤执行不能跳步、不能乱发挥管质量每一步都有校验不达标就自动修复杜绝幻觉管迭代踩过的坑永远堵死AI越用越稳不会重复犯错Harness 不是什么新技术它本质上是把我们已有的工程经验系统地应用到 AI 上。2026 年AI 工程化的核心竞争已经从「谁的模型更好」变成了「谁的 Harness 体系更强」二、典型案例—Harness Engineering业界典型落地案例案例 1HashiCorp 官方 Harness Engineering 落地实践—术语发起方1背景HashiCorp 用 AI Agent 维护 Terraform、Vault 等全球顶级开源项目之前核心痛点AI 生成的代码不符合架构规范、重复犯同样的错误、文档与代码不一致、PR 通过率极低人工审核成本极高。2Harness 核心落地动作构建了面向 AI 的完整架构规范体系所有设计文档、API 契约、编码规范全部结构化纳入代码仓库和代码实时同步更新搭建了原子化 Skill 库封装了 Terraform 开发、测试、文档生成、合规校验的全流程标准化能力建立了 “错误→规则迭代” 的强制闭环每一个被打回的 PR都转化为一条新的硬约束规则加入 Harness 体系。3量化成果PR 通过率从 21% 提升至 94%代码开发周期缩短 68%架构违规率下降 98%无重复错误出现。案例 2LangChain 生产级 Agent Harness 体系落地—AI Agent 领域头部1背景LangChain 在 Terminal Bench 全球 Agent 性能基准测试中同一款底层大模型Agent 性能排名仅 30 名开外核心痛点流程失控、工具调用错误、任务拆解混乱、长周期任务完成率极低。2Harness 核心落地动作完全不更换底层大模型仅优化 Harness 体系重构了系统提示模板、工具调用约束、流程管控规则、反馈闭环搭建了标准化 Skill 库每个工具都明确了调用规范、参数校验、异常处理、结果验证标准强制了 “Plan-Execute-Verify” 的闭环执行流程每一步执行后必须验证结果不通过就自动回溯修复。3量化成果同一款大模型Agent 性能排名从 30 跃升至全球前 5任务完成率提升 172%工具调用错误率下降 92%。案例 3OpenAI 官方 GPT-4o 代码解释器 Harness 体系—大模型原厂实践1背景GPT-4o 代码解释器上线初期用户核心投诉代码跑不通、文件操作错误、结果不符合要求、幻觉频发一次运行成功率不足 50%。2Harness 核心落地动作构建了完整的沙箱运行 Harness 环境给代码解释器定死了权限边界、执行规则、文件操作规范封装了标准化 Skill 库覆盖数据处理、文件操作、可视化、代码调试的全流程能力建立了 “代码生成→静态校验→沙箱运行→结果验证→自动修复” 的强制闭环代码必须通过校验才能运行结果不符合要求就自动重写。3量化成果代码一次运行成功率从 47% 提升至 91%用户满意度提升 83%文件操作错误率下降 96%。三、详细案例分析—claude code真正的Agent Harness工程Anthropic 官方 Harness 设计实践Harness design for long-running application developmentClaude Code 本身就是 agent harness 工程的典型实践——根据 Menlo Ventures 数据其占据企业 AI 编码市场约 54% 份额公开 GitHub 上 72% 的 agent 归属提交来自它是目前覆盖面最广的 agent 编码工具。核心是它把 “模型决定做什么Harness 负责怎么做” 。它没有试图成为 agent 本身。它没有强加僵化的工作流。它没有用精心设计的决策树去替模型做判断。它给模型提供了工具、知识、上下文管理和权限边界。打个比方如果 Agent 是一台发动机Harness 就是整车的刹车、方向盘、仪表盘和安全带——发动机再好没有这些你也开不上路。Claude Code一个 agent loop 工具(bash, read, write, edit, glob, grep, browser...) 按需 skill 加载 上下文压缩 子 agent 派生 带依赖图的任务系统 异步邮箱的团队协调 worktree 隔离的并行执行 权限治理1. 上下文管控—知识按需加载、子代理上下文隔离、三层上下文压缩上下文窗口有限但真实工作任务的信息量无上限。Harness 的职责是在有限窗口内让模型看到该看的忘掉该忘的。1知识按需加载问题如果把所有领域知识git 规范、测试模式、代码审查清单等全塞进 system prompt10 个 skill 各 2000 token 20000 token 起步且绝大多数与当前任务无关。方案两层注入架构。Skills按需加载匹配描述命中项目相关的上下文用一个轻量索引 MD N 个独立知识文件的分层结构索引常驻详情按需加载。2子代理上下文隔离问题agent 工作越久messages[] 越大。每读一个文件、每执行一条命令结果永久留在上下文里。这个项目用什么测试框架“可能只需读 5 个文件父代理的上下文却被这 5 个文件的全文永久污染。方案子代理用独立 messages[]完成后只返回一段摘要。3三层上下文压缩问题即使有 subagent 隔离和 skill 按需加载长时间工作中上下文仍会膨胀。读 30 个文件 运行 20 条命令 → 100K token → 超出窗口。方案三层递进的压缩策略。静默替换 → 自动压缩 → 手动压缩从无感逐步升级到可控Transcript 落盘信息不丢失只是移出活跃上下文压缩是 LLM 自身完成的——又是模型做决策harness 做执行”2. 可配置执行能力—工具热注册、Skill 文件系统、插件与扩展架构核心矛盾不同项目、不同领域需要不同的工具和知识。Harness 需要提供扩展机制但不能硬编码。按需加载工具“用到什么知识, 临时加载什么知识” – 通过 tool_result 注入, 不塞 system prompt。扩展体系Skill知识模块 MCP外部服务 Tool执行能力 文件即配置 协议即对接 注册即可用三者的 dispatch 机制统一都是模型调用工具名harness 查表并返回结果。1工具热注册问题从仅 bash 扩展到多工具如何保证循环不变、安全可控方案dispatch map 模式核心模式字典映射加一个工具 加一个 handler 加一个 schema 定义循环永不改动。路径沙箱safe_path在 handler 层面统一约束。2Skill 文件系统Skill 的本质是把知识也当作一种工具知识模块化可插拔通过同一套 dispatch 机制注入。3插件与扩展的架构潜力支持MCPModel Context Protocol外部能力接入 特点标准化协议、外部进程/服务、长连接 示例浏览器控制、数据库查询、第三方 API和 新增插件内部可管理Skills。3. 任务分解调度—TodoWritenag、子任务委托、DAG任务图、后台异步执行、多Agent团队核心矛盾复杂任务不能一步完成需要拆分、排序、分配、并行、跟踪。Harness 需要提供从清单到自主认领的完整调度链。1TodoWritenag机制问题多步骤任务中模型容易丢失目标——重复工作、跳过步骤、跑题。方案TodoManager nag 提醒注入两个硬约束同一时间只有 1 个 in_progress → 强制顺序聚焦超过 3 轮未更新 → 注入 reminder → 建立问责设计要点nag 不是提示模型而是注入到 tool_result 中作为硬提醒。模型无法忽略因为它就在当前消息流里。2子任务委托将大任务拆解后子任务可以委托给子代理执行。核心在于父代理只关心结果摘要不关心中间过程子代理的混沌被隔离在其独立 messages[] 中形成天然的关注点分离3持久化 DAG 任务图问题s03 的 TodoManager 是平面的、仅内存的——无排序、无依赖、压缩即丢失。真实任务有结构B 依赖 AC 和 D 可并行E 等 C 和 D 都完成。方案将清单升级为基于文件的 DAG 任务图4后台异步执行问题npm install、pytest、docker build耗时数分钟。阻塞式循环让模型空闲等待。装依赖的同时创建配置文件在阻塞模型下变成串行。方案daemon 线程 通知队列。5多 Agent 团队与执行空间隔离团队协作Agent Teams 多 agent 分工 握手协调。每个任务绑定一个独立的 git worktree并行任务不互相踩文件 。4. 硬约束与闭环反馈—路径沙箱、操作审批门控、Shutdown 握手核心矛盾模型的能力越强越需要清晰的边界。Harness 的职责不是信任模型而是在架构层面让模型做不到越界行为。1路径沙箱原则不是要求模型不越界而是在 handler 层物理阻止。每个文件操作 handler 都调用 safe_path()形成硬边界。模型无论如何构造路径参数都无法逃脱工作目录。2操作审批门控问题高风险操作删除文件、修改核心模块、关闭 teammate需要审批不能自动执行。方案统一的 request-response FSM。闭环关键reject 必然携带 feedback形成拒绝→改进→重提交的闭环而不是简单的 pass/fail。3Shutdown 握手问题直接杀线程 → 文件半写、config 处于不一致状态。需要优雅关闭。方案不是 kill 线程而是发送一个请求并等待 teammate 自己在合适时机退出。5. 熵增治理—对话归档、任务状态持久化、团队通信记录、生命周期事件流、项目知识沉淀核心矛盾agent 工作时间越长积累的信息债越多——代码变更无记录、决策过程无追溯、上下文膨胀、状态漂移。Harness 需要持续对抗熵增。1对话归档问题压缩上下文时旧消息会被摘要替代。虽然上下文干净了但完整历史消失了。方案压缩前先落盘先存档再压缩再让 LLM 生成摘要替换 messages。设计理念不丢信息只移出活跃上下文。事后可审计、可回放。2任务状态持久化问题会话结束 → 内存释放 → Todo 列表消失。下次会话从零开始没有任何继承。方案任务图落盘到 .tasks/状态与对话生命周期解耦。关键效果会话终止后任务状态依然存在新会话可以继承上一轮的任务图任务图 过程的结构化快照3团队通信记录multi-agent 协作中谁对谁说了什么、什么时间说的、决策依据是什么——如果没有记录事后完全不可追溯。方案JSONL append-only 信箱 天然的通信日志。4生命周期事件流问题创建/删除 worktree、完成任务——这些关键操作分布在代码各处没有统一的发生了什么的记录。方案集中的事件流事件类型create.before/after/failed、remove.before/after/failed、keep、task.completed。设计价值时序可追每一步操作有 before/after 事件状态可重建事件流 文件状态 → 完整历史失败可定位failed 事件标出异常点5项目知识沉淀CLAUDE.md MemoryClaude Code 的持久化知识体系CLAUDE.md 本质上是一个始终注入 system prompt 的知识模块Memory 系统是跨会话的状态持久化settings.json 是权限和行为的声明式配置这三者共同构成项目元知识层——不参与单次任务执行但持续影响 agent 的行为模式。CLAUDE.md → 项目级别架构、约定、注意事项相当于给 AI 的 README .claude/memory/ → 会话级别用户偏好、反馈、项目上下文、外部引用 .claude/settings.json → 配置级别权限、hooks、环境变量熵增来源 对抗机制 持久化形式 ────────────────────────────────────────────────────── 对话消息膨胀 三层压缩 归档 .transcripts/*.jsonl 任务状态漂移 持久化 DAG 任务图 .tasks/task_*.json 协作信息散落 JSONL 信箱 .team/inbox/*.jsonl 操作不可追溯 事件流 .worktrees/events.jsonl 会话间知识断裂 记忆系统 .claude/memory/*.md 项目约定遗忘 CLAUDE.md 项目根 CLAUDE.md四、实践指南—给团队负责人搭建Harness的行动手册如果把第三章拆解的 Claude Code 机制看作零件这一章的五个策略就是从零件中提炼出的五条设计原则——它们不绑定任何一个产品而是团队负责人在自己项目里搭建 Harness 体系时可以逐条对标的行动手册。1. 动态上下文治理—统一团队的知识入口防止各说各话Agent 已做上下文压缩、子代理隔离、知识按需加载——这些机制主流 Agent 已内置不需要你再造一套。人最容易搞乱什么同一个项目张三给 AI 贴一份 800 行的架构文档李四只甩一句帮我写个接口王五每次复制粘贴不同的代码规范——同一个 Agent 在不同人手里产出风格迥异的代码这才是上下文层面真正的熵增来源。你需要做什么——把项目知识当作代码一样管理。核心原则Agent 看不到的内容就不存在。你脑子里的架构决策、Slack 里口头交代的约定、Code Review 时说的这个模块别碰——Agent 统统不知道。因此所有影响编码质量的项目知识必须入仓用 Agent 能稳定解析的格式组织。项目知识分三类各居其位project/ ├── AGENTS.md ← 通用知识安全红线 编码规范摘要 文档索引Tech Lead 维护≤200行 ├── CLAUDE.md ← 符号链接 → AGENTS.md多工具兼容 │ ├── docs/ ← 领域知识Agent 按需加载每个文件 ≤300 行 │ ├── conventions.md ← 编码规范linter 覆盖不到的约定命名、目录职责、禁止模式 │ ├── business.md ← 业务规则术语表、核心流程、不能碰的遗留逻辑产品 Tech Lead │ ├── api-contract.md ← 接口契约API 端点、OpenAPI/GraphQL schema 路径后端 Owner │ ├──>2. 构建配置执行能力—统一工具链防止各装各的Agent 已做MCP、Skill、Tool 共用一套 dispatch 注册机制——模型负责调谁框架负责怎么调不用你操心。人最容易搞乱什么A 装了 GitHub MCP Brave SearchB 只用了 TerminalC 自己搭了套未经验证的社区 MCP Server。同样的任务分配给不同的人A 能做、B 做不了、C 做到一半 Server 挂了——经验无法复用踩的坑各自闷着。你需要做什么——建一个通用→定制→归档的三层工具体系。第一层获取通用编码工具。这些是所有项目共用的基础能力不需要自己造。主流获取渠道渠道内容怎么用MCP 市场mcp.so、Smithery、PulseMCP4,800 公开 Server按用途搜索先看 Star 数和最近更新时间优先官方维护的AgentSkillsHubGitHub62,000 项目10 维质量评分每 8 小时更新按评分排序高分段基本可靠Cline MCP MarketplaceVS Code 内一键安装适合 VS Code 用户省去手动配置各 Agent 内置工具集Claude Code/Cursor/Codex 自带的 bash、文件操作、搜索等不用配置开箱即用选型原则官方维护 活跃社区 久不更新的个人项目。基准测试中社区废弃的mcp-puppeteer可靠性 0%、mcp-git4%——装一个坏的工具比不装更糟。第二层构建项目业务 Skill。通用工具解决能做业务 Skill 解决做对。底软和通用软件项目常见的 Skill 方向项目类型典型 Skill把什么封装进去嵌入式/驱动hw-register-helper芯片寄存器映射表、位操作模板、硬件初始化序列协议开发protocol-validatorMIPI/I2C/SPI 协议时序约束、标准帧格式、常见错误模式驱动移植porting-checklist平台差异对照表、编译选项映射、中间件版本兼容矩阵通用后端api-scaffold项目统一的 API 结构模板、错误码规范、中间件链通用前端ui-component-builder设计系统组件清单、样式变量表、无障碍检查规则判断标准团队里有人反复手动做这件事超过三次 → 值得封装成 Skill。Skill 的本质是把一个人的经验变成所有人都能调用的工具。第三层建立团队 Skill 仓统一归档。避免各人本地散落、离职即丢失。team-skills/ ├── README.md ← 索引所有 Skill 的一览表 适用场景Tech Lead 维护 ├── hw-register-helper/ │ ├── SKILL.md ← Skill 定义触发描述、输入/输出、使用示例 │ ├── references/ ← 芯片手册摘要、寄存器映射表Agent 按需加载 │ └── scripts/ ← 配套脚本可选 ├── protocol-validator/ │ ├── SKILL.md │ └── references/ └── ... ← 每新增一个业务 Skill 就加一个目录两条规则Skill 仓本身就是一个 Git 仓库。版本可追溯谁改了什么都清楚。新人入职第一天克隆 Skill 仓。确保团队成员的工具起点一致。3. 有序任务调度—统一需求的拆解方式防止理解偏差层层放大Agent 已做任务清单、子代理派生、DAG 任务图、后台异步——主流 Agent 已有从清单到自主认领的完整调度链。人最容易搞乱什么同一个功能需求——A 的提示词是帮我写个登录接口B 写了 10 条验收条件 3 条边界约束——Agent 的产出天差地别。人不会定需求Agent 就不会正确执行。需求描述的不一致被 Agent 层层放大最后变成谁也看不懂的代码堆。你需要做什么——引入 SDD规范驱动开发让需求先变规范再变代码核心原则人写 SpecAgent 拆 Plan人 Review PlanAgent 执行人 Review 代码。人写 Spec业务意图 验收条件 边界约束 明确不做什么 ↓ Agent生成 Plan实现方案 技术选型 任务拆分 ↓ 人Review Plan方向对不对有没有遗漏复杂度是否合理 ← 关键节点 ↓ Agent拆 Tasks 逐条执行 ↓ 人Review 代码是否符合 Spec有无越界第一步选一个 SDD 框架作为团队统一入口。三种主流选择框架工作流最适合注意OpenSpec57k ★Propose → Apply → Archive已有项目改造、中小团队最轻量学习曲线最平缺少强制门控依赖人的自律Spec Kit106k ★Constitution → Specify → Plan → Tasks → Implement从零开始的新项目流程严格企业就绪上手比 OpenSpec 慢Superpowers43k ★Brainstorm → Plan → TDD 子代理执行 → 两轮审查 → 归档对代码质量要求严苛的团队TDD 铁律 File Handoffs 降 Token Durable Progress 防丢失执行纪律最强三者侧重点不同OpenSpec 管需求规格化把模糊需求变成可审计的 SpecSpec Kit 管全流程从宪法到实现的标准流水线Superpowers 管执行纪律强制 TDD 两轮审查代码质量最后一道防线。三者不互斥——中文社区主流实践是 Claude Code OpenSpec Superpowers 组合使用。推荐从 OpenSpec 起步——学习成本最低对现有项目的侵入最小。对代码质量有更高要求时叠加 Superpowers 作为执行层。第二步定一个统一的 Spec 模板包含四个固定部分需求描述一句话说清楚要做什么验收条件至少 3 条可测试的验收标准边界约束什么不能碰、什么不能改不做什么明确排除范围防止 Agent 过度发挥第三步设一个硬性节点——Plan 必须人点过头Agent 才能进入 Implement。这个节点是整个人-Agent 协作中最重要的质量控制点。4. 架构硬约束与闭环反馈—自动化门禁防止人忘了审查Agent 已做路径沙箱、操作审批、优雅退出——框架层已物理阻止了最危险的行为。人最容易搞乱什么Agent 不会主动放松门禁——人会。人会跳过 lint、随手加# noqa、看到 diff 太大懒得审查就直接 Approve、周五下午急着 merge 关了 CI 检查。人的省事是 Harness 体系最大的漏洞。你需要做什么——用三道自动化防线替代人的自律防线一Agent 执行时实时钩子 → 拦截危险命令、密钥泄露、配置篡改 ↓Agent 产出代码 防线二本地 git commit 钩子 → 禁止 # noqa / eslint-disable 等抑制注释 ↓提交到仓库 防线三CI 门禁 → 检测 diff 范围、测试覆盖、依赖变更、授权文件触摸 ↓通过后方可合入三道防线互不替代——Agent 绕过一道第二道在本地挡绕过两道第三道在服务端挡。配套开源工具按覆盖范围从轻到重工具防线位置覆盖什么适合AgentLint76 条规则防线一 二密钥泄露、配置篡改、抑制注释、危险命令——Agent 产出代码的即时检查中小团队快速起步集成 Claude Code/Cursor/Codex 等主流 AgentAgentGatenpm防线三PR 级别密钥泄露、文件越界、diff 过大、缺测试、依赖变更需要 CI 门禁的团队在 AgentLint 基础上加一道服务端防线Chunk CLICircleCI防线三挖掘团队 PR 历史生成团队专属审查规则——不是通用规则而是你团队历史上实际打回 PR 的那些原因有积累 PR Review 历史的成熟团队规则越用越准三者不互斥推荐 AgentLint AgentGate 组合覆盖三道防线。有 PR 历史积累后再上 Chunk CLI。5. 系统熵增治理—用 Agent 清扫 Agent 的产出防止坏模式指数级扩散Agent 已做对话归档、任务落盘、事件流记录、知识持久化——Agent 不会丢信息它会忠实地把所有过程保留下来。人最容易搞乱什么Agent 写的代码越多熵增越快——但这不是因为 Agent 写得差而是因为Agent 会把代码库里已有的坏模式当作合法做法然后忠实复制到更多模块。传统项目里技术债线性增长AI 项目里一个临时妥协能被 Agent 复制 10 次熵增是指数级的。人管不过来。你需要做什么——建立后台 GC 机制让规则帮你扫而不是你追着扫。核心思路像编程语言的垃圾回收一样对待代码库。GC 定期扫描堆内存、回收无用对象——代码库也需要同样的后台清扫机制。第一步把团队品味编码为可自动化检查的规则Golden Principles规则类型示例结构化要求所有日志必须 JSON 格式包含requestId和timestamp命名约定接口以I开头枚举以Enum结尾文件规模超过 500 行的文件自动标记需要重构禁止模式# noqa、ts-ignore、裸println——lint 规则拦截第二步配置后台扫描自动化执行频率做什么实现方式每日文档园丁对比docs/和实际代码发现不一致自动提 PRAgent GitHub Actions 定时触发每周代码 GC扫描 Golden Principles 违规自动提修复 PR自定义 lint 规则 CI每次失败Agent 犯了错 → 追问如何让它以后不再犯→ 加规则反馈回代码库手动触发逐步积累关键不在于扫描本身——扫描之后自动提 PR清理动作不需要人主动发起人只需要 Review 和 Merge。软件工程用了几十年学会管住人的不确定性。现在它需要学会管住模型的。五、总结Harness Engineering 不是什么新技术它本质上是把软件工程几十年的积累——分层架构、自动化测试、CI/CD、代码审查、技术债管理——系统性地应用到 AI Agent 上。区别只在于对象变了过去这些体系管的是人现在管的是模型。对团队负责人而言搭建 Harness 不需要一步到位。从一份手写的 AGENTS.md 开始从第一个重复犯错的坑开始堵从一个统一的 Spec 模板开始从一道 lint 门禁开始。每踩一个坑就彻底堵死它——这是 Mitchell Hashimoto 的原话也是 Harness Engineering 最朴素的实践入口。参考资料Claude Code 泄露后我终于看懂 Harness engineering了傻子可懂的 Harness Engineering 入门教程Harness Engineering驾驭工程【十字路口】探秘 Claude Code搞懂 Agent Harnesslearn-claude-code 项目Claude Code 源码分析项目Claude Code 源码解析从0到1开发一个基于Harness的Agent实战