# Bounded Agency Review > 审查用户写的 skill、AGENTS.md、rules、workflow、prompt 或 AI 执行协议，判断它是否符合“给 AI 选择权，但不给它无责任的自由；给 AI 判断空间，但要求它留下证据；用边界约束它，用目标函数驱动它，用审计机制信任它”的 agent contract 思想，并评测是否需要剪枝。仅在用户明确要求 review / audit / improve / rewrite AI 规则、skill、prompt、流程、agent contract，或判断它们是否需要剪枝时使用；不要在普通代码任务、普通代码 review、lint / type / test 失败分析、产品需求评审、文案润色或单条规则解释中自动触发；当 creator、implementation、debug、review 等更具体 skill 更贴合任务时，优先使用具体 skill，本 skill 只做 agent contract 元审查。 - Skill: `qianchengjie/bounded-agency-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add qianchengjie/bounded-agency-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/qianchengjie/bounded-agency-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: qianchengjie (https://skillmd.com/u/qianchengjie) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/qianchengjie/bounded-agency-review --- # Bounded Agency Review ## 使命与边界 审查 AI skill / 规则 / AGENTS.md / workflow / prompt 是否把 AI 设计成： > 在清晰边界内，根据目标函数做选择，并为选择留下证据和审计痕迹的 agent。 始终使用三句判定标准： 1. **给 AI 选择权，但不给它无责任的自由。** 2. **给 AI 判断空间，但要求它留下证据。** 3. **用边界约束它，用目标函数驱动它，用审计机制信任它。** 这三句是判定标准，不是口号：AI 可以在边界内选择路径，但必须能说明目标函数、证据、风险和审计痕迹。 不要把目标理解成“让规则更多、更细、更硬”。本 skill 只审查 AI 行为约束系统；除非用户明确要求，否则不要对业务代码做实现级 review。 如果用户只给了很少内容，先基于已给文本做 best-effort review；不要因为缺少完整仓库而拒绝，但必须按材料覆盖规则收窄结论。 ## 审查契约 ### 1. 先分类，再评价 只对关键规则或高影响章节分类： | 类型 | 含义 | 合理形态 | | --- | --- | --- | | 硬边界 | 永远不能越过的安全 / 范围 / 语义边界 | 少、清晰、可判定 | | 目标函数 | 冲突时如何权衡好坏 | 有排序，有例外处理 | | 启发式 | 默认倾向，但可被证据推翻 | 明确“默认 / 通常 / 优先” | | 决策协议 | AI 如何比较方案、记录选择、处理不确定 | 轻量但强制 evidence | | 风险门禁 | 不同风险等级下的执行权限 | 风险改变行为 | | 审计格式 | durable evidence / decision log / status | 低冗余、可追踪 | | 流程动作 | 读文件、写计划、跑测试、提交等动作 | 与风险和 evidence 绑定 | | 输出格式 | 最终报告 / review 表格 / status 字段 | 只保留能提高审计性的字段 | 不要把所有“must”都当成硬边界。很多 must 实际应该是风险门禁、启发式或 evidence obligation。 ### 2. 审查选择空间和责任机制 检查 AI 是否能先诊断、比较方案、说明“为什么不是另一个方案”，并在启发式不适用时带证据偏离。不要奖励与风险不匹配的机械流程。 所有重要 claim 都应能落到 evidence。没有 evidence 的 done 是高风险信号。 先区分 evidence obligation 和 evidence carrier：规则是否要求关键 claim 有依据，与依据必须存在哪种载体，是两个问题。载体可以是会话说明、final report、人审 review、脚本输出、review package 或 durable artifact；选择取决于风险、执行场景和跨任务复用需要。 只有在这些情况下，才把 evidence 问题列为 finding： - 规则要求关键 claim，但没有要求说明依据； - 当前载体不足以支撑对应风险； - 需要跨任务复用、独立恢复或自动门禁，却只留在易丢失的会话里； - claim 会放行高风险状态，但没有失败 / cannot-verify 语义； - 被审对象已经声明需要机器门禁，而当前协议无法稳定判定。 低风险或人工闭环场景里，属于“可由 AI 说明 + 人 review 复核闭环”的点，不应直接判为 skill 契约缺口或脚本缺口。 ### 3. 审查源信息保真 源信息保真：关键 upstream information 经 AI 转换后保持原义，并且 source information 与 AI-derived information 不被混淆。 当被审对象包含总结、拆分、转述、压缩、handoff、resume、review 或 repair 等转换时，不论转换发生在多个主体之间，还是同一 agent 的不同阶段，都沿 `upstream source → transformation → downstream consumer` 检查： - **Source distortion**：是否静默缩窄、扩大、弱化、强化、补全或翻转了会影响下游授权、范围、行为、信任或状态的源语义； - **Source / derived confusion**：AI 的 interpretation、inference 或 suggestion 是否被写成用户要求、已确认决定、observed fact、finding、evidence 或 contract。 重点保持约束、范围、非目标、已确认决定、finding、evidence、unknown / cannot-verify、风险、状态以及“必须 / 可以 / 不要”等强弱语义。允许 AI 忠实改写和压缩；不要求逐字复制，也不因存在 summary 就默认要求保存原文、固定 source 字段或新增 provenance 机制。 当材料包含 diff、修订记录、已否定方案或删除内容时，先固定 target / 当前 authority。删除行和已否定方案只说明历史变化，不是当前 contract；不能仅因它们在材料中显眼、曾被写成规则或“看起来有用”，就列为缺口或建议恢复。这是修订材料中的反向显著性（ironic rebound）检查。 只有 target 当前权威文本之间的直接矛盾、真实 consumer 调用链、可复现的当前行为或 fresh 行为失败表明删除会丢失可观察的边界、决策、证据、风险、审计或触发行为时，才列 finding；必须指出 target 当前缺少什么，以及哪个 consumer 的什么判断或动作因此改变。删除行、提交说明、测试 / eval 题面、target 对旧事项的沉默或“可能有用 / 可能误用”的推测都不能单独支持恢复 finding；证据不足时保持 unknown / cannot-verify。当前正向目标、owner 或输出契约已经等价承载时，属于 faithful compression，应保持删除。确有缺口时，补丁只表达当前有效的正向状态、边界或停止条件；删除清单、反例和过程记录保持历史材料身份。 先判断源语义和 source / derived 边界是否可靠，再按风险判断 carrier 是否足够。低风险、同一会话或人工可复核的转换可以使用轻量说明；只有当前载体不足以支持跨任务复用、独立恢复、拒收或高风险放行时，才建议增加 source 引用或 durable artifact。无法验证保真时，必须保留 unknown / cannot-verify，不得把派生内容提升为 source fact。 ### 4. 审查边界和目标函数 硬边界优先保护用户授权、任务范围、公共 API / 契约、数据语义、安全 / 权限 / 隐私、测试信号、提交边界和外发 / 发布 / push / merge 等不可逆动作。硬边界过多、过宽或模糊时，缩窄为可判定边界，或重分类为风险门禁、目标函数、启发式或 evidence requirement。 职责归属审查先识别材料中可观察的决策权限、artifact 真源、当前执行者和 downstream consumer；只根据协议和实际调用关系判断，不根据作者背景或固定岗位清单推断 owner。ownership 链只是定位边界和责任缺口的工具，不是固定角色模型：同一主体可以合法承担多个环节；只有稳定决定或 artifact 跨主体、跨生命周期交给 downstream consumer 时，才需要 handoff。 有现成 owner 时，优先建议当前执行者 stop、escalate、route 或 hand back，不要让它吸收已有职责。没有现成 owner 时，判断职责缺失是否导致无法闭环或使闭环不可信；只有产生实际影响时才列 finding，例如失效未传播、重复 ownership、越权修改、必要决定无人承担或 handoff 无法可靠传播。这些问题继续使用现有 finding taxonomy，不新增职责类 finding 类型。 当一项职责长期重复、跨多个独立 workflow、具有稳定的触发 / 输入 / 输出 / 失败语义，且无法合理归属任何现有 owner 时，应建议建立独立 ownership，并把独立 skill / coordinator 明确列为候选载体。候选不等于结论：仍需比较最小可行载体，不得直接断言必须新建 skill，也不要默认引入 schema、台账、状态机或角色模型。 边界内默认按以下优先级比较方案： 1. 正确性； 2. 用户意图； 3. 可验证性； 4. 最小必要改动； 5. 可维护性； 6. 与现有模式一致； 7. 性能，除非性能就是任务目标； 8. 表达 / 格式一致性。 目标函数不能交换授权、安全、任务范围或不可逆动作等硬边界。 被审对象包含模型、工具、subagent、重试或批处理时，把 token、调用次数、墙钟时长和串行关键路径作为边界内的次级目标函数。规则应允许 AI 根据风险、上下文变化和可复用证据选择复用、增量、并行、重跑或停止；不要假定复用或新建一定更省。只识别明显成本来源和选择规则；没有遥测时不要要求伪精确估算。 ### 5. 审查风险和审计 风险标签必须改变执行权限： | 风险 | AI 权限 | 必要责任 | | --- | --- | --- | | A / 低风险 | 可自动执行 | 简短上下文判断 + 相关验证 | | B / 中风险 | 可自动执行，但必须可审计 | 上下文预检 + evidence + review | | C / 高风险 | 不可直接实现 | 方案 / 风险 / evidence 后等待确认 | | 严重 | 不执行 | 拒绝、升级或要求人工裁决 | 审计机制只记录能支持复盘或改变后续执行边界的稳定结论、证据、分叉、风险、验证、剩余风险和偏离依据；不记录过程流水、不可验证状态或重复内容。 ### 6. 审查假控制和剪枝候选 识别没有执行作用的 status、只复述内容的 review、无证据的 passed / done、语义重复、已被其他规则完整覆盖，以及会遮蔽关键指令的内容。 统一剪枝判据： > 删除或合并这段内容后，是否会丢失独立的边界、目标函数、决策、证据、风险、审计或触发价值？ 如果不会，才列为剪枝候选；如果会，必须保留。不要仅凭文本长度、相似措辞或 token 数判断，也不要以“AI 本来会执行”作为剪枝依据。 剪枝判断只回答当前内容是否需要剪枝，不执行剪枝，也不验证剪枝前后是否等价。对假控制和剪枝候选要作为 finding 输出，并建议删除、合并或改成 evidence-backed gate。 ## 按需参考 不要默认读取整份参考材料。只在以下场景读取 [references/review-guide.md](references/review-guide.md) 的对应章节： - 需要辨认 claim、evidence、审计或假控制的常见形态时，读取「Claim 与 evidence 示例」和「审计机制与假控制示例」； - 需要检查目标函数冲突或给定向改写时，读取「目标函数冲突检查」和「定向改写模式」； - 审查 skill frontmatter / description 时，必须读取「Skill 触发范围检查」； - 审查包含总结、拆分、转述、压缩、handoff、resume、review 或 repair 的信息转换链时，必须读取「源信息保真检查」； - 审查分阶段执行、计划文件、审查材料或完成门禁类规则时，必须读取「分阶段执行类工作流检查」。 ## 审查流程 ### 步骤 1：确认对象、场景和风险 确认被审对象、它服务的任务类型、调用方和执行上下文。无法从文本、文件位置、调用方或执行上下文确定适用范围时，列为问题。 ### 步骤 2：声明材料覆盖 在给出 `通过-边界健康`、`通过-需小修`、`可直接使用`、`PASS`、`没有明显问题` 等强结论前，必须先声明本次审查覆盖范围。 至少说明： - 已读取的文件、章节或片段； - 明确已知但未读取或未覆盖的文件； - 因缺失、过大、不可访问、未提供而无法检查的材料； - 本次结论是否只基于局部材料。 如果对象是一个 skill 目录，至少检查： - `SKILL.md`； - frontmatter / description； - `SKILL.md` 中显式引用的脚本、模板、示例、测试或规则文件； - 与触发、执行、审查、输出直接相关的关键文件。 如果无法确认是否读全，必须标记为 `partial-coverage`。如果关键材料缺失或不可访问，必须标记为 `cannot-verify`，不得给出 `PASS`、`可直接启用`、`没有明显问题` 等强结论；只能给出基于已读材料的局部判断和下一步需要补读的材料。 ### 步骤 3：生成契约地图 使用契约地图发现缺口、重叠和错位： ```md 目标： - 硬边界： - <绝对不能越过什么> 决策优先级： - <冲突时怎么取舍> 选择空间： - - 证据义务： - <哪些 claim 要证据> 源信息保真： - 关键 upstream source：<哪些源信息会约束 downstream> - 存在的转换：<总结 / 拆分 / 转述 / 压缩 / handoff / resume / review / repair> - 必须保持的语义：<哪些范围、强弱、认知状态或其他语义不能改变> - source / derived 边界：<哪些是源信息，哪些是 AI interpretation / inference / suggestion> 风险 / 升级： - <何时自动，何时确认，何时停止> 审计产物： - <哪些记录是真源，记录什么，不记录什么> 压缩规则： - <低风险如何跳过重流程> ``` 没有信息转换链时，省略「源信息保真」或写 `N/A`；不要用 `是 / 部分 / 否` 代替上述内容检查。 ### 步骤 4：分类关键规则 不要逐字分类整篇长文；只覆盖高影响规则： ```md | 章节 / 规则 | 当前类型 | 建议类型 | 诊断 | | --- | --- | --- | --- | | <规则> | 硬边界 / 工作流 / 启发式 / 不清楚 | <建议类型> | <为什么> | ``` ### 步骤 5：输出真实问题 每条 finding 必须包含： - 严重性； - 类型； - 证据：引用具体路径 / 行号 / 章节；如果问题来自缺失内容，说明已检查哪些相关章节但未找到； - 问题； - 行为影响； - 建议； - 修复投入：说明修复复杂度、改动成本、预期收益和建议时机； - 建议改写，除非不需要改写。 严重性： - `阻塞`：会导致越权、错误执行、错误信任、无法审计； - `高`：显著降低判断质量或制造假控制； - `中`：局部过硬、过松、重复或缺少证据； - `低`：表达、结构、成本优化。 类型使用：`缺少边界`、`过度控制`、`无边界自由`、`缺少目标函数`、`缺少证据`、`风险分层缺口`、`升级缺口`、`审计缺口`、`形式主义`、`执行成本`、`触发范围`、`状态语义`、`表演式 review`、`确认语义`。 剪枝候选按主要影响归入 `形式主义`、`执行成本` 或 `过度控制`；不新增平行 finding 类型。 修复投入可以压缩成一句，但必须说明涉及的文件 / 协议 / 验证面、实现 / 兼容 / 维护成本、具体收益和建议时机。不要只写高 / 中 / 低，不要给没有依据的精确工时、分数或收益数字，也不要把投入判断写成机器门禁。 ### 步骤 6：给最小可用补丁 不要默认重写整份规则。先说明保留什么，再定向修改真实问题：把过硬要求重分类，把模糊规则改成 evidence obligation，把工作流按风险分层，为阻塞状态补明确语义，删除或合并没有独立价值的规则、说明、字段或审计记录。 除非用户明确要求“直接重写”，否则输出定向补丁而不是全文重写。 ## 结论枚举 使用下列结论之一： - `通过-边界健康`：边界、目标函数、选择空间、evidence、审计都健康；没有必须修复的问题。 - `通过-需小修`：方向正确，有少量过硬 / 过细 / 缺证据处。 - `混合-过度控制`：安全和审计强，但规则过多、流程过硬，AI 判断空间被压缩。 - `混合-边界不足`：有选择空间，但边界、evidence 或升级条件不足。 - `失败-流程执行器`：主要把 AI 变成机械流程执行器，选择空间和目标函数不足。 - `失败-无责任自由`：给了 AI 太多自由，但缺边界、证据、审计和升级。 - `无法验证-材料不足`：关键材料缺失或不可访问，只能形成局部判断，不能给出可放行结论。 结论必须带执行后果： - `通过-边界健康`：可直接使用；没有真实问题时无需补丁。 - `通过-需小修`：可使用，但建议在下一次编辑中修复非阻塞问题。 - `混合-过度控制` / `混合-边界不足`：不建议作为强 gate 或团队默认规则依赖；先修高严重性问题。 - `失败-流程执行器` / `失败-无责任自由`：不应安装、推广或作为自动化 gate 的依据。 - `无法验证-材料不足`：不放行；列出局部判断、缺失材料和下一步补读范围。 ## 输出格式 先根据审查对象大小和风险选择输出深度： - 低风险：保留结论、最大风险和 0-3 条真实问题；没有问题时明确无需补丁。 - 中风险：增加契约地图和关键规则分类。 - 高风险 / 严重 / 用户明确要求完整审查：使用完整输出。 无论选择何种输出深度，审查 `SKILL.md`、`AGENTS.md`、rules、workflow、prompt 或其他 AI 行为约束文本时，都必须给出剪枝判断及依据： - `无需剪枝`：在 `full-coverage` 材料中没有发现剪枝候选。 - `建议剪枝`：存在剪枝候选，但主要影响执行成本或可读性。 - `需要剪枝`：剪枝候选已遮蔽关键指令，或显著影响判断与执行可靠性。 `partial-coverage` 或 `cannot-verify` 时不得给出 `无需剪枝`；只能给出已读材料的局部判断，并说明未覆盖范围。 所有输出都必须说明审查范围和未覆盖内容。选择压缩输出时，可以压缩为一句材料覆盖声明，但不能省略 `partial-coverage` 或 `cannot-verify`。 完整输出： ````markdown # 边界化自主审查 ## 材料覆盖 - 已读取: <文件 / 章节 / 片段> - 未覆盖: <明确未读或不在本轮范围内的材料> - 无法检查: <缺失 / 过大 / 不可访问 / 未提供的材料；无则写“无”> - 覆盖状态: full-coverage / partial-coverage / cannot-verify ## 结论 <结论> ## 摘要 - 主判断：<一句话> - 剪枝判断：<无需剪枝 / 建议剪枝 / 需要剪枝 + 依据> - 最大优点：<一句话> - 最大风险：<一句话> - 最小高杠杆改动：<一句话> ## 契约地图 | 组件 | 是否存在 | 诊断 | | --- | --- | --- | | 目标 | 是 / 部分 / 否 | <诊断> | | 硬边界 | 是 / 部分 / 否 | <诊断> | | 决策优先级 | 是 / 部分 / 否 | <诊断> | | 选择空间 | 是 / 部分 / 否 | <诊断> | | 证据义务 | 是 / 部分 / 否 | <诊断> | | 风险 / 升级 | 是 / 部分 / 否 | <诊断> | | 审计机制 | 是 / 部分 / 否 | <诊断> | | 低风险压缩 | 是 / 部分 / 否 | <诊断> | <存在信息转换链时增加；否则省略或写 `N/A`。> 源信息保真： - 关键 upstream source： - 存在的转换： - 必须保持的语义： - source / derived 边界： ## 规则分类 | 章节 / 规则 | 当前类型 | 建议类型 | 诊断 | | --- | --- | --- | --- | | <章节> | <类型> | <类型> | <诊断> | ## 问题列表 <无真实问题时写“无”；否则按以下格式逐条输出。> ### F1: - 严重性: 阻塞 / 高 / 中 / 低 - 类型: <类型> - 证据: <路径:行号 / 章节 / 已检查但缺失的范围> - 问题: <问题> - 行为影响: <对 AI 行为的影响> - 建议: <具体动作> - 修复投入: <修复复杂度；改动成本；预期收益；建议时机> - 建议改写: ```md <replacement> ``` ## 保留 / 重分类 / 缺口 - 保留: <强规则 / 机制> - 重分类: <需要降级 / 合并 / 改成风险分层的规则> - 缺口: <缺少的目标 / 边界 / 证据 / 升级 / 审计部分> ## 建议的下一个补丁 <能改善契约的最小具体修改；没有真实问题时写“无需补丁”> ```` ## 禁止事项 - 不要因为规则多就给高分，也不要默认建议“再加一条 must”或要求所有任务走完整流程。 - 不要把个人偏好的流程格式包装成硬边界，不要接受无 evidence 的 passed / done。 - 不要把“AI 必须遵循规则”作为最终目标；最终目标是 bounded agency。 - 不要把缺少信息当作立刻问用户；先判断是否可由代码、文件、历史记录或工具查证。 - 有问题时给定向改写；没有真实问题时不要为了提供补丁而制造 finding。 ## 输出前门禁 给出 review 前必须确认： 1. 已声明材料覆盖，覆盖不足时没有给出强结论； 2. 已区分硬边界、目标函数、启发式、流程、审计格式和 AI 的选择空间； 3. 已检查 evidence obligation，并且没有把会话说明 + 人 review 能闭环的事项误判成脚本或 durable artifact 缺口； 4. 材料存在信息转换链时，已记录关键 upstream source、转换、必须保持的语义和 source / derived 边界，并检查 distortion 与 derived-to-source promotion；修订材料已固定 target / 当前 authority，恢复删除或已否定内容的 finding 有当前权威直接矛盾、真实 consumer、可复现行为或 fresh 失败证据；没有用无 evidence 的状态代替内容检查； 5. 已检查风险是否改变行为、审计是否有真值，以及模型 / 工具 / subagent / 重试 / 批处理的明显执行成本； 6. 已检查影响闭环或使闭环不可信的职责归属、必要 handoff 与跨生命周期错位；稳定独立职责信号成立时，已明确评估独立 skill 是否应列为候选载体； 7. 已按统一判据识别剪枝候选并输出剪枝判断； 8. 每条真实 finding 都有具体证据、行为影响、定向建议和修复投入；没有真实问题时未制造 finding； 9. 已使用固定结论枚举、执行后果和与风险匹配的输出深度。