可执行
治理判断必须影响下一步，而不只是生成说明。
面向 Coding Agent 的治理工程
让 Coding Agent每一次改动，都有依据可查。
把目标、约束、工程方法、行动判断与验证证据，编织进 Agent 的执行过程。
行动前参与判断，执行中改变下一步，交付时留下可复核事实与未知项。
免费下载 Windows 版Governance Engineering
什么是治理工程？
治理不是任务结束后生成一份报告，而是在行动前参与判断，在执行中改变下一步，并在交付时留下可复核的事实与未知项。
- 01治理意图
目标、约束与验收要求
- 02行动判断
发现、方法与影响范围
- 03执行影响
改变下一步操作与检查点
- 04证据记录
执行事实、结果与未知项
工程化，意味着它能够进入执行、留下证据、接受复核。
可追溯
从结果回到行动判断、工具调用与原始事实。
可复核
明确区分已确认事实、推断与尚未解决的未知。
规则不是贴在流程之外，而是成为 Agent 工作方式的一部分。
治理方法必须改变下一步。
发现：修改已完成，但尚无修改后的实际测试结果。
对操作的影响：运行原有测试，用真实输出判断是否修复。
变更必要性
避免为了修改而修改。
系统诊断
让下一步回应已观察到的原因。
结构熵控制
限制无关改动与重复实现。
证据化交付
区分做过什么与确认了什么。
Aegis × Autoloom
同一套治理方法，两种使用方式。
选择独立的方法包，让现有 Coding Agent 使用治理工程；或使用已经把治理 checkpoint、轨迹与记录组合进执行过程的 Autoloom。
Aegis
把治理方法安装到支持 Skills 的 Coding Agent Host。
- 跨 Host 使用
- 方法与工作流开源
- 由 Aegis 仓库持续演进
Autoloom
把方法、执行 checkpoint、完整轨迹和治理记录组合成 Windows 产品。
- 执行时自动进入相关判断点
- 轨迹与治理记录可回看
- 无需另行安装 Aegis
两者共享治理工程方向，各自保留清楚的产品、安装与版本边界。
一项改动，留下四层可复核依据。
这些信息进入会话记录，可以从结果回到原始执行过程。
- 01
目标与来源
任务范围、验收要求、相关来源
- 02
行动判断
发现、采用的方法、对操作的影响
- 03
执行事实
工具调用、命令结果、文件观察
- 04
交付记录
结果、证据引用、未知项
轨迹让执行过程可以回看。
按轮次查看上下文、模型输出、工具调用、参数、结果与时间。
治理页把分散事实组织成完整记录。
从治理概览进入行动评估、检查点、执行事实与工作结果。
治理影响 → 检查点 → 执行事实 → 结果记录
记录帮助复核，不等同于对任务正确性的保证。
40 秒，看完治理工程如何进入一次真实任务。
- 1发现问题
- 2形成治理影响
- 3执行修改
- 4运行原有检查
- 5记录结果
本次演示3 项失败 → 4 项通过1 个实现文件修改原有测试未改动
治理之外，边界也必须清楚。
- 权限模式
- 决定 Agent 可以读取、修改或执行什么。
- 模型连接
- 使用受支持的账户或 API 配置。
- 项目位置
- 工作区在本机；模型请求可能发送相关上下文。
- 会话记录
- 任务、工具结果与治理事实可以回看。
关于治理工程
治理会让 Agent 变慢吗？
治理只在相关决策点进入执行，并复用同一 Agent 与会话。具体成本取决于任务、模型和实际检查。
治理记录是否等于结果正确？
不会。治理记录说明依据、执行事实与未知项；它不替代用户验收，也不构成正确性保证。
项目数据会发到哪里？
工作区位于本机或你连接的 SSH 主机；模型请求可能向所选服务商发送相关上下文，具体取决于任务与配置。
哪些操作需要授权？
权限模式决定 Agent 可以读取、修改或执行什么；需要确认的操作会在执行前请求你的决定。