would-agents-actually

智能体真的会这样做吗？

针对已固定版本的智能体系统，基于证据给出判断：在声明的任务、工具、策略、预算和试验条件下，它会执行还是避免某项已定义的操作。明确区分系统声称的内容、轨迹记录的内容，以及环境证实的内容。

命令语法

• /would-agents-actually help：显示约定、判定标签和必需的系统固定信息，不进行研究。
• /would-agents-actually verdict <agent-action question>：研究该主张，运行或检查所需的操作证据，给出有证据支持的判断，并验证产物。

流程

1. 将操作定义为 [a]。说明机会或触发条件、固定版本的系统、可观察到的操作或弃权、任务分布、环境、时间窗口、预算、实际阻力、比较对象和独立回读。只有在未知信息会改变证据计划时才提出一个问题；否则说明假设。
2. 固定模型标识符和版本、提供商路由、提示词、运行时、规划器、路由器、验证器、重试、回退方案、工具、架构、权限、审批关卡、记忆、上下文、检查点、环境、依赖项、任务抽样和预算。任何实质性变更都会形成新的系统分层。
3. 在研究或试验前，写明支持、矛盾和证据不足的条件。将目标结果、目标轨迹、匹配的类比案例、组件检查、机制证据和推断分别记录。当前报告或快速变化的运行时行为很重要时，加载 recent-public-signal.md。
4. 在一手记录中核实每个关键来源。填写 verdict-protocol.md 中的来源卡和轨迹卡。判定或置信度所依赖的每项前提，都必须有两个独立团队、任务集或数据集的支持。相同的任务、运行、评分者和改述只计一次。
5. 只有经过独立环境回读，才将外部操作计为已完成。计划、最终声明、工具调用尝试、已接受的请求或冗长轨迹都不能证明结果。将模型导致的诊断与基础设施导致的诊断分开，同时在操作层面的判断中保留两者。
6. 在查看结果前定义参考类别。匹配操作、任务、时间范围、工具、权限、状态、运行时、模型版本、环境、评分者、预算、故障、威胁条件和时间。不能只凭模型名称迁移分数。
7. 收集证据后，加载 frameworks.md，诊断机会、选择、尝试、接收、状态、约束、验证、停止、可重复性和迁移性。将能力、倾向、可靠性、合规性、韧性、弃权和操作适配度分别评估。
8. 按照 verdict-protocol.md 选择 LIKELY、UNLIKELY、UNCERTAIN 或 INSUFFICIENT EVIDENCE。如果无法或不允许进行实时研究，则使用 UNVALIDATED HYPOTHESIS。绝不捏造运行、轨迹、工具调用、状态变更、评分结果、比率、成本、引文、来源或 URL。
9. 设计权限最小、最贴近生产环境的测试。预先规定代表性任务、留出集、试验次数、分母、比较对象、评分者、预算、权限、故障、停止规则、回读、回滚、清理和决策变化。使用获批数据或合成数据，并采用虚假或可撤销的副作用。
10. 使用 output-template.md 生成结果，将其保存在已安装技能之外，然后运行 mise run validate-verdict --input <verdict.md>。退出码 0 表示产物符合必需格式。退出码 1 表示内容不完整。退出码 2 表示命令或输入路径有误。
11. 每完成一个重要步骤后，将查询、来源、系统固定信息、任务标识、排除的运行、故障、回读、假设和验证输出追加到外部研究日志。如果无法核实关键来源、权限、回读或安全控制，则停止并报告缺失项。

加载条件

• 当基准测试、试验、评分器或传输证据可能为分析提供参考时，加载 evidence-base.md，随后在使用前重新核查每个一手来源。
• 创建判定时，加载 verdict-template.md。将其复制到 assets/ 目录之外；不要编辑已安装的模板。
• 对于帮助命令，加载 help.md；对于经过研究的判定，加载 verdict-insufficient-evidence.md；当系统固定版本或实时研究缺失时，加载 failure-unvalidated.md。
• 编写工件后，运行 mise run validate-verdict。只有在更改验证器合约时，才阅读 mise run tests-test-validate-verdict。
• 在更改行为、触发边界或评估用例之前，阅读 contract.md。
• 只有在维护或重新打包此技能时，才加载 generation-contract.md。

注意事项

• 组件检查成功并不能证明整个操作成功。
• pass@k、pass^k、单次运行成功率、操作倾向和部署可靠性回答的是不同问题。
• 结果评分器、轨迹评分器、约束评分器和基础设施评分器不能互相替代。
• 未报告两种视角之前，不要从操作分母中剔除设置、依赖项、传输、超时、权限或速率限制故障。
• 切勿仅为让测试更贴近实际而添加凭据、支付权限、破坏性访问权限或广泛权限。
• 在敏感领域，只判断已定义的操作。不要推断总体安全性、有效性、合法性、资格、授权、合规性或行动许可。

完成标准

• [a] 固定系统、操作、机会、任务、时间窗口、成本、比较对象和读回。
• 每项关键前提均通过独立性门槛。
• 结果、轨迹、约束、评分器有效性、基础设施、成本和传输分别处理。
• 试验、符合条件的分母、丢弃的运行、不确定性和任务集中度均清晰可见。
• 置信度受最薄弱的前提、评分器、独立性检查和传输桥接限制。
• 下一项测试采用最小权限，并设置预算、停止规则、读回、回滚和清理措施。
• 每个关键来源都提供可见 URL。
• 验证器输出 "status": "PASS" 并以 0 退出。

工厂执行合约

可接受的结果是：根据真实工具轨迹、环境证明和执行阻碍，判断 Agent 能否完成指定操作。更改最小范围的责任归属，同时保留当前 Agent 操作判定行为。

1. 使用 mise run ci 冻结当前软件包并记录其摘要。
2. 运行 mise run domain-research-policy，随后判断当前 Agent 操作判定的来源和反证。
3. 对指定的 Agent 操作判定任务运行 mise run agentic-request。语义选择由模型负责。
4. 运行 mise run decision-policy、mise run ci 和行为评估。回到失败层级中最底层的责任方。
5. 运行 mise run invocation-policy -- <receipt>，并为每项任务提供依据，或说明领域特定的不适用情况。
6. 可选运行 mise run improvement-policy。只有在任何受保护维度都未退化时，才保留单一维度的更改。

只有在需要其合约时，才通过 mise run use-case-policy 加载 assets/use-case-contract.json，并通过 mise run evals 加载 evals/evals.json。

Mise 负责可重复的机制、顺序、回执和检查。模型负责解读、因果判断、创造性工作，以及代码无法提供的直接感知。若缺少授权、证据过时或门槛未通过，则停止。