agent-harness-review 用于审查一个智能体运行框架或智能体设计。其目标是用最简单、刚好够用的框架完成任务：只有当增加智能体、子智能体、技能、插件或钩子能够带来可测量收益时才增加；删除部件与“不改变”都是合法结论。审查范围应匹配请求的规模：若问题只涉及一个子智能体，就只回答一个问题；若审查整套配置，则需开展完整的盘点。
使用方式上，建议先收集证据再作判断。需要盘点以下几类内容：
- 每个会话都会加载的内容，包括指令文件、技能列表（数量、名称与描述是否近似重复）、插件（每个插件可能带来技能、钩子、MCP 服务器与智能体）、MCP 服务器，以及注入上下文的子智能体与钩子。
- 实际使用情况：Claude Code 的会话记录（~/.claude/projects/**/*.jsonl）会记录技能调用（“name”:“Skill”）、子智能体类型（“subagent_type”）与 MCP 调用（mcp__<server>__）；Codex 的会话保存在 ~/.codex/sessions。低使用率只是线索，不是定论：某个领域技能即使很少调用，仍可能是正确的技能。
- 客户端行为：需阅读客户端的当前文档，弄清某项设置覆盖什么、禁用某项会移除什么。在 Claude Code 中，skillOverrides 不适用于插件技能；禁用插件也会断开其 MCP 服务器，但插件的 MCP 服务器可重新添加为用户级服务器。
审查会参照多份来源的结论进行核对：
- 从简单开始并设计好工具：路径可预测时，优先采用单次调用或固定工作流；开放式任务才使用智能体。保持设计简单，展示智能体的计划，并像对待提示词一样认真设计智能体与计算机之间的接口，包括清晰的工具描述与示例、相似工具之间的边界、模型易于书写的格式，以及让错误难以发生的参数（如用绝对路径而非相对路径）。
- 委派广度，而不委派共享决策：智能体使用的 token 约为聊天形式的 4 倍，多智能体系统约为 15 倍，因此任务必须值得这些成本。多智能体适合超出单个上下文、广度优先、并行、以读取为主的工作；不适合需要共享上下文或相互依赖的场景，而这覆盖了大多数编程工作。并行写入者若没有共享上下文，会产生冲突结果，因此默认只使用一个写入线程，用子智能体来回答问题。子智能体的委派提示应包含目标、输出格式、工具或来源以及边界；智能体数量应随任务规模变化（回答一个事实用 1 个智能体、3 至 10 次工具调用，做比较用 2 至 4 个，只有大范围调研才更多）；长结果应写入文件并回传引用，而不是经由主智能体转述。
- 划分大型并行工作并核对证据：Claude Opus 5.5 在并行子智能体各自独立（如每个子智能体负责一个服务）且主智能体在接受前核对每个子智能体证据时，能较好地完成长审查与迁移。这与单一写入者规则一致：并行写入者使用不同文件或工作树，不做共享决策。长任务应把任务清单保存在文件中，明确“完成”的含义以及期望停下的位置，并在需要尽快完成时给主智能体时间预算或已用时间。
- 保持常列技能集小而互异：研究显示，列出 1,000 个无关技能时，智能体加载相关技能的比例从 73.6% 降至 27.4%，51.6% 的任务什么也没加载（原为 9.3%）。仅隐藏无关技能的描述，在很大程度上恢复了加载率；预选技能保持 73.9% 的召回率；要求智能体规划技能使用则达不到该水平。应关闭未使用的技能包，合并近似重复项，保持描述互异，然后再考虑为未被选中的技能添加触发词。
- 技能的成本可能超过其收益：在 307 个由技能导致的失败（125 个功能失败、182 个效率失败）中，功能失败主要来自看似相关但导致智能体错误实现部分任务或遗漏任务的技能；效率成本最大的是技能强制要求、不管任务规模都执行的检查（67 个）与重型构建流水线（30 个）；仅提示词长度并不能解释这些成本。应检查技能的检查与流程是否随变更规模而变化，并把可疑技能与同一任务下的无技能运行作比较。
- 模型设置与指令措辞：努力程度是主要控制项，从中等开始，xhigh 和 max 留给已测得质量提升的工作；移除“仔细思考”之类的句子；写明应避免的过早停止与期望的停止，对破坏性操作保留确认，并标记粘贴的文本。
报告时先给出结论及其证据，包括实测使用情况、配置或文档事实，以及来源发现。已做的改动（可逆、带备份）与需要所有者账号、资金或发布的决策应分开；还要说明哪些是实测、哪些是从设置与用户不同的来源推断而来。