Harness 机制与配置工程

本页从 [[wiki/concepts/上下文管理与 Harness Engineering]] 拆出，收录 Claude Code 定制化机制、Skill/Goal 工程、Hooks、上下文压缩与 Token 经济学等运行机制细节；核心框架见母页。

CC 定制化体系：七种机制的工程选择

Claude Code 提供了七种定制机制，它们在加载时机、压缩行为和权重三个维度上各不相同。完整理解这些差异是 Harness 工程的基本功。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: Anthropic 七种方法]] [[raw/2026-06-19/邵猛/驾驭Claude Code：七种指令全解析.md|来源: 邵猛七种解析]] [[raw/2026-06-19/扶苏/Claude Code 深度定制指南.md|来源: 扶苏深度定制]]

机制	加载时机	压缩后行为	权重（权威性）	最佳用途
CLAUDE.md	会话启动全程保留，子目录按需加载	压缩后重新读取	高	代码库事实、项目约定、硬约束
Rules	支持 paths 路径限定按需加载	同 CLAUDE.md	高	局部约束、模块级规则
Skills	只加载名称+描述，正文调用时全量	共享预算内重新注入，先进先出	中	可复用流程、操作手册
Subagents	独立上下文窗口启动，仅结果回主会话	不压缩（独立上下文）	低（报告给主会话）	隔离重活、并行探索
Hooks	触发时确定性执行，绕开上下文	不消耗上下文 token	最高（强制执行）	自动化检查、安全拦截
Output Styles	注入系统提示且永不压缩	永不压缩但替换默认编码指令	中（注意替换风险）	角色定位、输出格式
append-system-prompt	始终加载	同系统提示	高	全局偏好、个人习惯

选择决策框架

邵猛提炼的选择框架：代码库事实进 CLAUDE.md、局部约束用路径限定 Rules、可复用流程用 Skills、隔离重活用 Subagents、确定性自动化用 Hooks、角色定位用 Output Styles。 [[raw/2026-06-19/邵猛/七种指令全解析.md|来源: 选择框架]]

金色传说大聪明深化了这个区分：Skills vs Subagents 的选择原则是”能否看到中间过程”——需要逐步干预用 Skills，隔离运行只要最终结论用 Subagents。Skill 被调用后压缩时会重新注入，但多个 Skill 共享 token 预算，最早调用的先被丢弃。 [[raw/2026-06-19/金色传说大聪明/深入理解Claude Code.md|来源: 金色传说大聪明 Skills vs Subagents]]

Output Styles 的隐藏风险

Output Styles 默认替换系统提示中的默认编码指令（如何控制改动范围、何时加注释、安全问题处理、验证习惯等）。如果使用自定义 Output Style，必须设 keep-coding-instructions: true 保留这些关键指令，否则会导致模型在编码行为上的质量退化。 [[raw/2026-06-19/Anthropic/七种方法.md|来源: Output Styles 风险]]

其他关键配置

claudeMdExcludes：开发者可跳过不相关团队的子目录 CLAUDE.md 文件
Managed Settings：组织级强制管控，管理员部署无法被个人配置排除
Plugin 打包共享：Skills/Subagents/Hooks/Output Styles 可以打包成 Plugin 在团队和项目间共享

Subagents 的异步模式

扶苏指出了 Subagents 的一个重要用法——Async Agents（异步智能体）：Ctrl+B 后台运行，完成后回来查看。Subagents 是保持主上下文清洁的关键，Plan Mode 中的 Explore 类型 subagent 是典型应用。Slash Commands 可显式编排复杂行为：在单条消息中并行启动多个 Subagents 做多渠道研究。[[raw/2026-06-19/扶苏/Claude Code 深度定制指南.md|来源: 扶苏 Async Agents]]

Skill 工程：从提示词到工业级进化体系

Skill 不是”加了文件名的提示词”。它是程序性记忆——跨任务可复用的知识固化，与 Prompt（单次指令）有本质区别。[[raw/2026-06-19/尼恩/阿里面试官：如何设计工业级 Skills 进化体系.md|来源: 尼恩 - Skill 本质]]

“拆自己的工作流程”设计哲学

脸谱君提出的核心设计方法：Skill 设计的核心能力不是懂 AI，而是会拆解自己的工作流程。 从”我怎么做”出发而非从”AI 能做什么”出发。[[raw/2026-06-19/脸谱君/我是怎么设计出那套竞品分析 Skill 的.md|来源: 脸谱君设计哲学]]

COP-DRR 六环节框架

脸谱君提出的系统化 Skill 设计方法论（适用于团队交付和安全敏感场景）：

C - Context：定义 Skill 的使用场景和触发条件
O - Objective：明确 Skill 要达成的目标
P - Process：设计执行步骤（建议用状态机图替代线性步骤，含分支和循环的回溯机制）
D - Decision：识别流程中的分支决策点
R - Rule：制定三层规则金字塔
Red-teaming：至少 5 个对抗测试用例——是 Skill 从”能用”到”可靠”的分水岭

浅版→深版的三步升级法：加边界（10 分钟）→ 加决策（15 分钟）→ 加对抗测试（30 分钟）。

三层规则金字塔

比平铺清单更可靠的规则系统：

层级	性质	违反后果
L1 硬约束	不可违反的安全/合规规则	立即阻断执行
L2 质量门禁	影响输出质量的关键标准	标注偏差但放行
L3 风格建议	偏好性指导	仅供参考

源码级底层机制

吴师兄从 Claude Code 源码中发现的关键常量揭示 Skill 的底层约束：[[raw/2026-06-19/吴师兄/一个月给 Claude Code 烧了 1.5 万美金.md|来源: 吴师兄 - Skill 源码]]

SKILL_BUDGET_CONTEXT_PERCENT = 0.01：所有 Skill 描述列表只占上下文窗口的 1%
MAX_LISTING_DESC_CHARS = 250：单条 Skill 描述超过 250 字符直接截断——头 250 字符决定 95% 的触发生死
Skill 是文件夹不是文件：五层架构（SKILL.md + references/ + scripts/ + assets/ + config.json）
Description 是触发条件不是简介——描述决定了模型是否调用该 Skill。用 if-条件句式描述触发场景

GEPA 自进化闭环

尼恩提出的工业级 Skill 进化体系：四层 Infra 架构 + 核心技术组件。[[raw/2026-06-19/尼恩/工业级 Skills 进化体系.md|来源: 尼恩 GEPA]]

四层架构：轨迹感知层 → 技能蒸馏层 → 技能进化层(GEPA) → 技能治理层。每层解决不可替代的核心问题。

GEPA 闭环：Generate（执行）→ Evaluate（评估质量）→ Patch（根据偏差修补）→ Audit（回归验证通过后更新）。

技能注册中心：三层校验（Schema 安全扫描冲突检测）、四层召回机制、三层渐进式加载（L0 目录 L1 摘要 L2 全文）。

脏计数器（Dirty Counter）：按有效工具调用次数而非对话轮数触发复盘——更精确地反映实际工作负载。

影子 Agent 舱壁隔离：六维度隔离（记忆隔离、递归防护、工具白名单、危险命令自动拒绝、前端输出隔离、日志隔离）。

边车文件模式（Sidecar Pattern）：Skill 内容与使用统计分离存储，原子替换 + 跨进程文件锁。

缓存继承：约 26% 端到端算力成本降低。

四状态双向可逆状态机：active（活跃）/ stale（过时）/ archived（归档）/ pinned（锁定），支持双向复活。

五维质量评估体系：42+ 细分指标完整的量化体系（含计算公式、优秀阈值、告警阈值、处置策略），覆盖任务达成率/工具健康度/输出稳定性/人工干预率/Token 成本。

Practical Gotchas

吴师兄总结了 Skill 编写中最有价值的坑点清单（从 3 条被 Claude”喂”到 22 条）：

三十帧后截图：长时间运行的 Skill 需考虑渲染一致性
CDN 缓存刷新：涉及资源的操作必须等缓存生效
配色 token 约束：LLM 对颜色的精确控制天然弱，需显式约束
PreToolUse hook 做调用频次埋点：量化识别主力 Skill 和僵尸 Skill
临时 hook 在 Skill 激活期间生效的”保险丝”用法（禁止修改指定目录外的文件）

Skills vs Subagents 选择原则

维度	Skills	Subagents
上下文	与主会话共享上下文	独立上下文窗口
交互性	可见中间过程，可逐步干预	隔离运行，只要最终结论
Token 成本	加载后进入 token 预算	完全独立预算
压缩行为	压缩后重新注入，共享预算先进先出	不压缩
适用场景	可复用流程、操作手册	隔离重活、并行探索、长线任务

六组件概念边界

尼恩提供的完整对比表，从概念层面明确了不同组件的定位：

组件	Core 定位	解决问题	边界特征	生命周期
Tool	能做	原子操作	无状态、无记忆	单次
Skill	会做	流程编排	有上下文、可组合	跨会话
Harness	不出事	可靠性	约束+监控+治理	永久
MCP	远程工具互联	标准化扩展	网络协议	按需
Memory	笔记本	持久化信息	跨会话	长期
Prompt	临时便签	单次指令	无状态	单次

从 Task-Driven 到 Goal-Driven 与 Goal 模式

24h 打工人项目的关键洞察：Task-Driven 解决执行问题，Goal-Driven 解决迭代问题。当前者成熟后（稳定执行、完整留痕、Skill 沉淀），可以升级到后者——系统不只等你派活，而是围绕目标自主向前走。但这需要 5 个前提：目标清晰、边界清晰、状态可见、过程留痕、权限可控。Goal-Driven 不是更放权，而是更强约束下的有限自治。 [[raw/2026-05-07/腾讯程序员/十年老技术开发的 AI Agent 探索之路.md|来源: 腾讯程序员 - 24h 打工人]]

/goal 模式的本质：时间驱动 vs 目标驱动

Claude Code 和 Codex 都支持高层执行模式，但 /loop 和 /goal 代表完全不同的范式：[[raw/2026-06-17/Guide/面试官：-loop 和 -goal 区别是什么？.md|来源: /loop vs /goal]]

/loop：时间驱动轮询。设定固定时间间隔唤醒检查。“下次什么时候醒？“适合监控、轮询类任务。
/goal：目标驱动完成。设定验收标准，自主执行直到满足条件。“什么时候算做完？“适合长线开发任务。

AllenTang 进一步澄清了 Agent Loop 五阶段（Perceive → Reason → Plan → Act → Observe）与 Goal 模式的关系——Harness 是 Loop 外面的运行环境，负责循环开始前的上下文/工具准备、中途的验证/预算监控、结束后的状态持久化、出错时的重试/熔断。[[raw/2026-06-19/AllenTang/一文搞懂 Loop 工程、Harness 工程、FDE.md|来源: AllenTang Loop 与 Harness 边界]]

好 Goal 的四要素框架

陈蛋黄提出的四要素框架（对比现有 wiki 的三要素——outcome + measurable success criteria + boundary conditions——新增了停止条件作为独立维度）：[[raw/2026-06-19/陈蛋黄/Codex Goal 模式生存指南.md|来源: 陈蛋黄 Goal 四要素]]

目标要硬：具体的可验证结果。如”用户注册功能”→“用户能用邮箱+密码注册，收到确认邮件，数据库 users 表新增记录”
证据要严谨：验收标准必须包含可执行的验证步骤（运行测试、浏览器截图等），不是”代码看起来没问题”
边界是枷锁：明确允许范围和禁止事项，防止 Goal drift 越界（如”只能修改 src/ 下的文件”）
停止条件是缰绳：含超时熔断和条件触发中止（如”相同 blocker 连续出现两次则停止”、“超过 50 轮循环熔断”）

执行前要求模式（陈蛋黄 + Wise Wong）：Goal 正文开始前，要求 Agent 先读文档和 AGENTS.md、输出理解确认、发现冲突暂停——这是防止误解的预检机制。

Goal 的哲学视角（陈蛋黄）：Goal 是人和机器之间的一纸契约，不是下达指令——目标是验收标准不是任务描述。

最终审计不可省略

长任务结束时，Agent 会随上下文压缩弱化原始 Goal 中的要求。必须强制执行：重新读文档、逐条对齐验收标准、git status 为证。[[raw/2026-06-19/陈蛋黄/Codex Goal 生存指南.md|来源: 陈蛋黄最终审计]]

矛盾：好的 goal 三要素：具体的 outcome、可衡量的成功标准、明确的边界条件 vs 好 Goal 四要素：目标、证据、边界、停止条件（增加了停止条件作为独立维度）来自 [[陈蛋黄]]

生产级 Harness 关键机制（04-27~05-06 补遗）

长任务合同（李泽宇）

AI 跑长任务前必须填写的边界协议——目标、允许改动范围、验证标准、停止条件、子代理介入规则。“长任务不是授权问题，是验收问题。执行可以放开，验收不能放开。“[[raw/2026-04-29/李泽宇的AI实验室/如何让Codex自主编码10小时，秘籍开源.md|来源: Codex 10 小时自主编码]]

Evidence Depth（证据深度）

回归测试分层体系，每条回归面标注证据到达了哪一层（单元/集成/E2E），一眼看出哪些信心是实的、哪些是虚的。来自李泽宇 300 亿 Token / 30 万行代码的 Harness 实践。[[raw/2026-04-29/李泽宇的AI实验室/300 亿 Token，30 万行代码，30万字烧出来的Harness实践，我开源了.md|来源: 300 亿 Token Harness]]

Rule + Skill + Script 三层分离（白家杰）

能自动化的检查全自动化（Script），不能自动化的靠声明式规则做事前预防（Rule），可复用的流程封装为 Skill。“人的品味只需要表达一次，之后每行代码都被自动守护。” 项目 always-applied 规则从 14 条/1010 行砍到 4 条/275 行。[[raw/2026-04-28/白家杰/Harness Engineering实践心得：如何高效驾驭AI？.md|来源: Harness 实践心得]]

元架构五路由（Meta_Kim）

任务先分类为 5 种路由（小改动/跨文件/跨模块/审查/沉淀），再决定 Agent 编排方式。已纳入 4 个平台：Claude Code（最完整）、Codex、OpenClaw、Cursor。[[raw/2026-04-29/金先森是朝鲜族阿/老金开源了个支持含CC、Codex等4个平台的编程治理框架.md|来源: Meta_Kim 框架]]

iii Harness：15 项职责与 Worker 组合模型（2026-06 新增）

Mike Piccolo（iii 创始人 & CEO）发表了一篇”如何构建你自己的 Agent Harness”的长文，核心诊断是当前框架模式的痛点在职责 bundling（打包），而非缺功能。生产级 Harness 至少承担 15 项职责：

#	职责	简要说明
1	接收并持久化 turn 请求	客户端发起一次对话轮次
2	解析模型 provider 凭证	安全获取 API key/token
3	查询模型能力	vision、tools、streaming、context window
4	驱动 per-turn 状态机	provision→stream→tool→steer→teardown
5	加载 skill 文档	描述每个 function 的请求格式、错误码
6	组装 system prompt	mode/identity/working directory/默认 skills
7	向客户端流式返回 token	实时 UI 体验
8	工具调用策略检查	policy engine，执行前拦截
9	人工审批	需要人决策的 tool call 暂停并恢复
10	LLM 预算追踪	workspace/agent 级别 spend cap
11	hook 机制	tool call 前后 logging/redaction/副作用
12	分支式 session 存储	支持 fork、resume
13	context compaction	上下文窗口满时压缩历史
14	事件流	UI 订阅 agent 状态变化
15	分布式 tracing	OpenTelemetry，跨步骤串联调试

iii 的解法是 worker + trigger 总线：每项职责对应一个独立 worker，通过 WebSocket 连到共享 engine，注册 function 和 trigger，任意 worker 可独立版本化、独立替换、任意语言实现。[[raw/2026-06-01/邵猛/如何构建你自己的 Agent Harness？超越 Cursor - Codex - Claude Code，告别一次性 SDK 选型，15 项职责独立各自可替换升级.md|来源: iii Harness 15 职责]]

Thin vs Thick：不是二选一的架构重写，而是 config.yaml 里增减 worker。同一 wire protocol、同一 trace shape、同一 observability story。框架模型的局限在于”框架替你选了 slider 上的位置并锁死”，worker 模型把 slider 留给你。[[raw/2026-06-01/邵猛/如何构建你自己的 Agent Harness？.md|来源: iii Thin vs Thick]]

与 Anthropic Harness 研究对照：Anthropic 侧重单任务质量与长程 coherence（task harness），iii 侧重基础设施 composability 与生产治理（runtime harness）。不互斥，完整生产系统需要同时考虑。 [[raw/2026-06-01/邵猛/如何构建你自己的 Agent Harness？.md|来源: iii vs Anthropic]]

上下文压缩横向对比：六家产品六种哲学（2026-06 新增）

腾讯程序员系统拆解了六家主流 AI 编程 Agent 的上下文压缩策略，揭示了这件事没有最优解，每种选择背后都是取舍： [[raw/2026-06-08/腾讯程序员/横向拆解Claude Code、Codex等六大Agent上下文压缩策略后，我们做了第 7 个.md|来源: 六家压缩策略对比]]

产品	核心策略	设计哲学
Claude Code	五段流水线，按成本递增排列	便宜的本地操作先上，LLM 摘要兜底
Codex CLI	保留近期用户消息原文，其余全部替换为 handoff 摘要	用户说的话最准确，模型说的可以重写
OpenCode	时间戳标记隐藏 + 结构化摘要 + 回放最后一条用户消息	不真删，理论上可恢复
Cline	`/smol` 生成摘要后在同一任务内接续	自动 + 手动双模式
Cursor	自动摘要 + 提示开新对话 + 历史可搜索	压缩后仍能回溯原始历史
Amp	不做递归压缩，用 `/handoff` 开新线程携带要点	长对话本身就是问题，换线程比压缩好
MemGPT/Letta	上下文 = RAM，历史 = 磁盘，Agent 自主换入换出	操作系统级的内存调度

第一代压缩的反面教训：悬崖式触发（不溢出不动→溢出全量压）、全量摘要丢细节（变量名/函数签名/错误堆栈一起丢）、Token 估算粗糙（中英混合误差 30-50%）、不区分信息价值（5000 行 grep 和 5000 token 关键诊断等量对待）。MUR AI 最终落地的四级水位线方案是针对云端多用户场景的实用解法。

Hooks 机制：给 AI 编码的五个关键时刻装上刹车（2026-06 新增）

吕昭波系统阐述了 Hooks 在 AI 编码中的关键作用——不是让 AI 写得更快，而是让 AI 写得更安全。防线速度跟不上生成速度是核心矛盾：AI 生成 100 行代码 30 秒，传统 PR Review 链路 2-4 小时。 [[raw/2026-06-05/吕昭波/别让 AI 写完代码就跑了：Hooks + Pre-commit，给 AI 编码装上刹车.md|来源: Hooks 机制]]

五道防线 + 传统 Pre-commit = 完整拦截网：

时机	事件	能干什么	是否阻断
用户提交 Prompt 后	`UserPromptSubmit`	检查是否含敏感信息	✅ 阻断
工具调用前	`PreToolUse`	拦截危险命令	✅ 阻断
工具调用后	`PostToolUse`	自动格式化、跑 Lint	不阻断
工具调用失败	`PostToolUseFailure`	记录日志、发送告警	不阻断
Agent 停止时	`Stop`	保存对话历史、生成摘要	不阻断

Hook 机制的深度应用（2026-06 增补）

金色传说大聪明补充了全部八个 Hook 事件：PreToolUse、PostToolUse、PermissionRequest、SessionStart、PreCompact、Stop、SubagentStop、UserPromptSubmit。其中 UserPromptSubmit 和 Stop 是高级自动化入口。Hooks 的 prompt 和 agent 类型虽然触发条件是确定性的，但输出由 Claude 判断——比纯确定性 hooks 灵活。 [[raw/2026-06-19/金色传说大聪明/深入理解Claude Code.md|来源: 金色传说大聪明八个事件]]

扶苏的深度实践构建了完整的 Hook 驱动工作流：[[raw/2026-06-19/扶苏/Claude Code 深度实战半年单兵重构30万行代码的硬核工程化指南.md|来源: 扶苏 Hook 实践]]

Skill Auto-Activation：UserPromptSubmit hook 基于关键词分析注入 Skill 激活提醒，不必等模型自己想起该用什么 skill
Stop Event 后置守护：扫描变更文件中的高风险模式（硬编码密钥、数据库操作无 Sentry 捕获等），可配置 skill-rules.json 管理规则
Build Checker：错误 < 5 自动修复，>= 5 转给 auto-error-resolver Subagent——明确的自主 vs 升级阈值
PM2 + Hook 自主调试模式：Claude 自主运行 pm2 logs、pm2 restart、pm2 monit，无需人类介入——实现真正的自主调试闭环

ContextBucket：Agent 记忆与工作区统一底座（2026-06 新增）

火山引擎的 ContextBucket 托管服务为 Agent 上下文困境提供了系统性解法——在同一套底座内同时收敛三类断层：记忆随会话消失、工作文件无法跨实例持久化、多 Agent 共用存储的权限与审计混乱。 [[raw/2026-06-04/火山引擎存储/ContextBucket：Agent 的-无限-记忆与工作区底座.md|来源: ContextBucket]]

核心技术：

向量 + BM25 + Rerank 多路检索：三路召回合并重排，Agent 不需要区分”该问记忆还是该问文件”
智能提取：只自动识别并存储关键事实（需求决策、技术结论、用户偏好），过程噪声不沉淀
FUSE 挂载工作区：文件远端持久化，跨机器只需重新挂载即可续接，Agent 侧无需感知
ContextSet 多租隔离：千万级原生隔离，记忆与工作区文件共享同一套凭证与端点

实测数据（Locomo 评测集）：正确率 16.45% → 64.14%（↑48 百分点），LLM 输出 Token 减少 80%，计费 Token 减少 43.2%。

与 TencentDB Agent Memory 的互补（见 [[wiki/concepts/Agent 原理、记忆与上下文工程]]）：ContextBucket 偏云端托管和企业级底座，TencentDB Agent Memory 偏开源插拔和本地优先。两者都解决共同的核心问题——Agent 记忆无法跨会话/跨设备持久化。

Token 经济学：KV Cache 的成本真相（2026-06-17 新增）

王卓（腾讯云开发者）揭示了 AI 编码成本由不可见的系统级 token 消耗主导，而非用户输入。理解 KV cache 机制、配置分层和会话管理可在同预算下省 3-5 倍。 [[raw/2026-06-17/王卓/一文搞懂Token经济学：同样额度多干3倍活，只需理解消耗机制.md|来源: 王卓 Token 经济学]]

KV Cache 定价（Claude）：缓存写 = base × 1.25；缓存读 = base × 0.1；未缓存 = base × 1.0。Opus 缓存读（$0.50/M）比 Haiku 基础输入（$1/M）还便宜。

有无缓存的指数级差异：无缓存时 10 轮 ≈ 26 万全价 token（O(N²) 增长）；有缓存时 ≈ 6.2 万等价 token（省 76%，近线性 O(N) 增长）。缓存仅前缀有效——链中间任何改动都会使其后所有缓存失效；切模型 = 完全冷启动。

四层配置成本（由低到高）：Memory（全注入、~800 token、任何改动断缓存）→ Rules .mdc（常驻缓存 ×0.1 或触发式零成本）→ Skills（加载前零成本、加载后 5k-15k 不可逆）→ MCP 工具（schema ~200-500 token/工具，永久税，结果永久累积）。

Sub-Agent 经济学：Sub-Agent 无法复用主 Agent 缓存（每次冷启动）。其价值是上下文隔离，而非省钱。

七大常见误解（破除）：长对话不会更贵（缓存命中使其比新会话更便宜）；/compact 会断缓存；Sub-Agent 不省 token；用户输入通常只占总输入 token 的 1-5%——「你打的那句话只是冰山一角，真正的成本是看不见的 99%」。 [[raw/2026-06-17/王卓/一文搞懂Token经济学：同样额度多干3倍活，只需理解消耗机制.md|来源: 王卓七大误解]]

是sudden 的 KV Cache 解释补上了一个更底层的成本直觉：缓存命中本质是复用已经算好的 Key/Value，未命中则要重新计算上下文的 KV；命中率 = 命中 token 数 / 总输入 token 数。长系统提示词、稳定前缀和重复上下文如果能保持不变，就能用缓存读价复用；反过来，频繁改 prompt 前缀、切模型、压缩会话都会破坏缓存。[[raw/2026-07-03/是sudden哦/一文说清大模型缓存命中机制，同样的token，命中和未命中价格相差120倍！不懂KV Cache的人，每个月都在白烧钱.md|来源: KV Cache]]

生产级 Agent 运行时九大子系统（2026-07 新增）

ElonMax 的 11 万行 Rust Agent 运行时案例把生产级 Harness 拆成九类子系统：带确定性守卫的 Agentic Execution Loop、多 Provider 编排、分层 Context 组装、工具执行安全框架、多 Agent 编排、全渠道消息网关、持久记忆与自进化、MCP 协议集成、CDP 浏览器自动化。这个拆解的核心判断是：生产级 Agent 不是 prompt + API，而是一套为 LLM 不确定性兜底的软件系统。[[raw/2026-07-03/ElonMax/实践出真知！直接拿去用！生产级 AI 智能体 9 大子系统全景解析！.md|来源: 生产级 Agent 九大子系统]]

其中最值得并入本页的是三组机制：每轮循环前用确定性代码注入执行契约，避免模型遗忘当前阶段和未完成验收项；每轮结束后用结构化 LLM-as-Judge 加证据门禁判断是否真有进展；工具执行按风险分级，默认模式、AutoReview、FullAccess 对应不同信任边界。它们共同说明 Harness 的关键不是”让 Agent 更自由”，而是把自由限制在可观察、可回滚、可验收的运行时里。[[raw/2026-07-03/ElonMax/实践出真知！直接拿去用！生产级 AI 智能体 9 大子系统全景解析！.md|来源: 生产级 Agent 九大子系统]]

从 SPEC 到七角色 Harness 的落地路径（2026-07 补充）

Ryo Kusnadi 的 crypto-snapshot-cli 案例提供了一条从零搭 Harness 的工程顺序：先写 SPEC，再加关键 Rule，再把编译/测试/校验固化成 Skill；单 Agent 开始失稳后，再拆成需求分析师、方案架构师、Gatekeeper、开发者、Code Reviewer、QA/Tester 和纯路由 PM。这个顺序的价值在于避免一开始就堆 Agent：复杂度是被失败逼出来的，不是为了看起来先进而引入的。[[raw/2026-07-05/P—nHub兄弟网站/从零搭建 Harness Engineering 框架：Rule、Skill、Sub-Agent等工程落完整路径.md|来源: 从零搭建 Harness Engineering]]

这篇文章把 Rule、Skill、Sub-Agent、Workflow、Script、MCP 的边界讲得很清楚：Rule 是团队政策，Skill 是 SOP，Sub-Agent 是角色分工，Workflow 是交接协议，Script 是客观裁判，MCP 是外部系统接口层。最关键的落点是主校验脚本：编译、测试、lint、依赖同步、覆盖率和结构校验必须汇总成统一后置关卡，把”AI 说完成”切换成”系统证明通过”。它还补充了两类项目级记忆：dev-map 处理代码导航，Task Board 处理需求/阶段历史；成熟 Harness 不依赖 AI 记住对话，而是让仓库用版本化产物记住状态。