| name | agent-harness-zh |
| description | 用于围绕项目实际使用场景和任务逻辑设计、诊断和改造通用智能体运行框架，判断是否需要额外控制层，并给出最小必要结构或最小修正与验证方案。
当用户需要设计或评审智能体架构、分析长任务失败、判断问题是否属于运行框架层，或提到“harness”“运行框架”“编排”“状态管理”“检查点”“恢复”“评估”“人工接管”“可观测性”时使用。
|
通用智能体运行框架
版本: 1.1.0
最后更新: 2026-03-26
目标
本技能用于一件事：
围绕项目的实际使用场景和真实任务逻辑，判断智能体是否需要额外运行框架层；如果需要，确定最小必要结构；如果已有实现存在问题，先定位主要问题，再给出最小修正和验证方案。
它不是为了把系统做复杂，也不是默认要求加规划层、长期记忆、检查点、评估器或人工接管。
场景优先原则
运行框架不是直接服务于“抽象任务”，而是服务于任务在真实项目里的使用方式。
同一个任务逻辑，在不同使用场景下，合理架构可能完全不同。
至少先判断这些维度，再做运行框架结论：
- 谁在使用，或者什么系统在调用
- 是同步交互、异步处理、批处理还是事件驱动
- 对时延、吞吐、成本的要求
- 对错误、延迟和降级的容忍度
- 是否存在真实副作用、权限风险或合规要求
- 失败后是否允许人工接管，以及接管成本
如果这些维度还不清楚，就不要直接下运行框架结论。
文件分工
SKILL.md：主入口。定义目标、模式、流程、输出要求和硬约束。TEMPLATE.md：固定输出模板。设计新项目和审查旧系统都按这里的结构产出。REFERENCE.md：判据库。提供失败模式、可观察信号、反模式、厚薄判断和优先检查顺序。ADVANCED.md：高阶判断。只在存在多假设竞争、是否需要结构性改造不明确、或者需要验证取舍时再读取。
默认读取顺序
- 先读当前
SKILL.md。
- 需要稳定输出格式时，读
TEMPLATE.md。
- 需要判断问题类型、失败模式、结构取舍时，读
REFERENCE.md。
- 只有在复杂歧义场景下，才读
ADVANCED.md。
适用模式
设计模式
用于新项目启动、旧系统重构前的结构设计、或者任务升级后的重新定界。
输出重点：
- 项目实际使用场景
- 任务逻辑
- 完成条件与中断条件
- 运行框架厚度判断
- 最小必要结构
- 明确不引入的结构
- 落地和验证计划
审查模式
用于现有系统诊断、失败复盘、结构评估、改造优先级排序。
输出重点：
- 项目实际使用场景
- 当前症状
- 证据
- 任务逻辑与假设
- 问题归类
- 主要问题
- 最小修正
- 验证计划
- 验证状态
何时使用
- 需要判断某个智能体到底需不需要厚运行框架。
- 需要判断问题是任务定义、模型、提示、工具，还是运行框架层的问题。
- 需要为长流程、多步骤、有副作用、可恢复要求高的任务设计结构。
- 需要给现有系统做运行框架审查或最小改造。
- 需要把“为什么加这一层、为什么不加那一层”说清楚。
何时不要使用
- 单轮、低风险、无外部动作的简单问答。
- 只有内容润色、提示微调，而没有结构判断需求。
- 缺少任务目标、完成条件和基本上下文，无法判断是否真是运行框架问题。
输入要求
设计模式最少需要
- 项目实际使用场景
- 任务目标
- 主要输入
- 主要输出
- 完成条件
- 主要动作
- 外部依赖
- 副作用或风险
审查模式最少需要
- 项目实际使用场景
- 现象或失败症状
- 当前实现的关键信息
- 已知证据
- 任务目标和完成条件
- 近期失败样本、日志、指标或行为描述
如果输入不全，不要假装已经定位完成；要明确写出当前假设和缺失信息。
必须输出的东西
无论设计还是审查，都必须满足以下要求：
- 明确当前模式。
- 先写项目实际使用场景、任务逻辑和当前假设。
- 明确说明当前架构是否与场景匹配。
- 明确说明主要问题是否真属于运行框架层。
- 只抓一个主要问题或一个主要结构决策，不要一轮同时摊开很多主问题。
- 每个判断都要给证据，或者明确说明目前缺少证据。
- 给出最小必要结构或最小修正，不默认做大改造。
- 给出验证计划。
- 没有验证结果时，不得宣称已经改进成功。
执行流程
- 识别当前是设计模式还是审查模式。
- 先判断项目的实际使用场景、服务对象、触发方式、时延要求、风险和容错边界。
- 再抽取任务逻辑、完成条件、中断条件和关键假设。
- 判断当前架构是否首先与场景匹配，再判断问题是否真属于运行框架层，而不是任务定义、模型能力、提示组织或工具契约问题。
- 基于场景和任务逻辑，判断运行框架厚度应当是极简、基础还是强化。
- 找出一个当前最重要的结构决策或主要问题。
- 给出最小必要结构或最小修正方案。
- 说明哪些结构明确不引入，以及不引入的理由。
- 设计验证方案，并在没有验证前保持保守结论。
核心约束
- 不为了运行框架而做运行框架。
- 不脱离项目实际使用场景讨论架构。
- 不把模块齐全当成目标。
- 不默认加入规划层、长期记忆、检查点、独立评估、人工接管。
- 不把一次失败直接推断成结构性问题。
- 不把重试当成完整恢复策略。
- 不把观察到的症状直接当成根因。
- 不在证据不足时过度归因。
- 不在没有验证的情况下宣称优化已经成功。
默认闭环
本技能默认围绕以下闭环工作：
- 发现一个主要问题或一个主要结构决策
- 提供证据或明确证据缺口
- 给出最小必要改动
- 给出验证方案
- 验证成功前不宣称改进完成
输出要求
默认使用 TEMPLATE.md 中对应模式的模板输出。
如果用户没有要求长文，保持结论紧凑，但不要省略以下内容：
- 项目实际使用场景
- 任务逻辑与假设
- 场景与架构匹配判断
- 主要判断
- 证据
- 最小改动
- 验证计划
- 当前验证状态
与其他问题的边界
当一个问题更像下面这些类型时，应先说明它不主要属于运行框架层：
- 项目真实使用场景尚未识别
- 任务目标本身不清
- 模型能力上限不够
- 提示词组织明显错误
- 工具接口本身不稳定
- 数据源本身有问题
只有当问题出在状态组织、阶段边界、控制点、恢复策略、验证闭环、人工接管、观测与停止条件等层面时，才应优先归到运行框架层。
结束标准
只有满足以下条件，才可以把结论写成“已形成改进建议”：
- 已明确项目实际使用场景
- 已明确任务逻辑和假设
- 已明确场景与架构是否匹配
- 已明确主要问题或主要结构决策
- 已给出证据或证据缺口
- 已给出最小修正或最小必要结构
- 已给出验证方法
只有在真正验证通过后，才可以写成“已确认改进成功”。
