确定责任、风险、反模式和可跟踪性需求
随着代理变得更有能力，想象责任转移到系统可能很诱人。 不是。 执行工作的可能是代理系统，但对结果负责并对执行的管理及控制承担责任的仍是人类。
在本单元中，你将学习
谁负责代理操作和结果
代理系统中出现哪些常见风险和反模式
GitHub如何通过控制措施来缓解这些风险
可信系统为何需要可追溯性和可观测性
责任不会随执行而移动
当代理创建拉取请求、修改代码或响应反馈时，它将参与工作流，但它不假定结果的所有权。 责任方仍然是以下人员和团队：
定义任务
设置权限
选择和配置控件
批准生成的更改
拉取请求评审模型明确说明：系统可以提出建议，但人类决定接受哪些内容。
常见风险和反模式
早期代理系统通常以可预测的方式失败：
无计划执行 代理开始更改代码，而无需明确的可检查方法。
过度权限的代理：代理（或其工作流令牌/工具凭据）拥有超过必要的访问权限。
隐藏推理工作流仅公开输出（代码差异），而不包括中间产物（计划、假设、决策点、执行上下文）。
对自动化的盲目信任需要警惕，通过 CI 是重要的，但检查只验证它们被设计检测的内容。 通过的构建并不自动意味着更改已完成、合适或低风险。
实施映射：风险→ GitHub缓解
| 风险/反模式 | 使用GitHub控制措施 | |
|---|---|---|
| 无计划执行 | PR 有差异， 但没有计划或理由 | 需要通过 PR 模板制定计划部分;在合并之前需要审阅 |
| 权限过多的代理 | 工作流可以写入存储库，广泛访问机密 | 最小权限GITHUB_TOKEN、具有所需审阅者的环境、限制谁可以触发工作流程 |
| 隐藏推理 | 无假设/范围/决策线索 | 在 PR 评论中需要计划和链接工作流运行过程并记录决策 |
| 自动化中的盲目信任 | “CI 通过，发布”的工作观念 | 将检查与 CODEOWNERS、所需评审和基于风险的审批相结合 |
可追溯性和可观测性
要很好地监督代理，你需要的不仅仅是最终的差异，而是一个完整的记录。 在GitHub中，该线索可以包括：
拉取请求和提交历史记录
查看评论和批准
工作流运行和上传的项目（测试报告、日志）
代码扫描上传和警报
机密扫描警报和推送保护事件
组织审核日志事件（可用性和访问权限取决于组织/企业配置）
目标不仅仅是合规性。 这是运营理解：当出现故障时，你需要知道发生了哪些更改、谁批准了这些更动、有何证据，以及接下来发生了什么。
代理贡献的最低审核线索
明确的目标（问题链接或 PR 描述）
可审查的计划（PR计划部分或文件）
受限的变更集（分支和提交）
自动化证据（工作流运行和工件）
人类判断（审查和批准）
明确的结果（合并、还原或升级）
假设代理的漏洞修复通过了 CI，然而后来却引发了回归错误。 关键问题不仅是代理是否犯了错误，而且是系统是否使错误理解和可预防：
是否有可见的计划和范围？
是否已请求合适的审核者（并且他们批准了吗）？
这些检查是否与变化的风险相符？
审核线索是否足以重建所发生的事情？
代理系统会更改谁执行工作，但不是谁拥有结果。 人类团队仍然负有责任，这就是为什么他们必须避免常见的反模式进行设计，并通过GitHub原生工件和日志实现强大的可追溯性。
了解责任的工作原理后，最后一步是决定代理工作应如何判断。 在下一单元中，你将参与者模型应用到代理生成的输出。