技能介绍

硬规则不该只活在散文里

当你的项目规则写着"不要编辑生成文件"或"永远不要写入这个工作区之外"时，代理在运行时读到的只是一段自然语言。问题在于，自然语言是模糊的——代理可能在边界上做出不一致的判断，而事后也没有证据说明它是否遵循了规则。对于涉及客户数据或迁移操作的场景，这种不确定性尤其危险：要么过度信任代理，要么在每次运行后人工审查所有操作日志。

这个技能的做法是用 Pluribus 配方，把硬边界规则转换成结构化的 policy.v1 收据。

核心能力

收据不是审计日志，而是一个极简的边界元数据记录，包含以下字段：

intended_targets：代理考虑过的文件、服务、命令或操作
policy_decisions：每个目标的明确 allowed 或 refused 决策，附带简短原因
write_started：策略决策之后，变更是否真的开始执行
post_write_guard：写入后的轻量检查，比如 grep、lint、schema 校验或路径守卫
stopped_at：当策略要求拒绝时，代理实际停止的位置

这样的收据有两个直接用途。审查者可以在一次运行之后快速确认代理没有越过边界，而后续代理可以在执行新任务前读取收据，了解前一次运行时做了哪些判断以及为什么。

适用边界

需要明确一点：这个技能不存储 prompt、对话记录、原始代码、密钥、堆栈跟踪或工具输出。收据只包含边界元数据，因此它是可以安全分享的——你可以把它提交到仓库里，或附加到 CI 的运行产物中。

但它不适合替代细粒度的访问控制。如果你需要代理完全无法触达某个路径或服务，应该在系统层面做隔离，而不是指望运行时自觉。收据的价值在于审计和可追溯，而不是阻止。对于简单的路径限制，一个静态分析 hook 可能更轻量。对于复杂的多步骤决策链，你可能需要更完整的策略引擎。这个技能解决的是中间地带：规则已经存在，但代理运行时缺乏结构化的执行证据。