当持续集成门禁标记一个人工智能生成的拉取请求时，重要的问题不仅是“它标记了什么？”
还包括：
“其他人日后能否重新推导出发出此发现的原因？”
这就是我在代理门禁 v0.2.1 版本中添加证据快照的原因。
什么是代理门禁
代理门禁是一个用于处理人工智能生成拉取请求的吉特哈布动作。
它不使用大型语言模型审查代码。它在持续集成中检查确定性的合并证据：
- 拉取请求范围溢出
- 吉特哈布动作权限提升
- AGENTS.md / .mcp.json 配置漂移
- 缺少测试文件证据
- 高风险路径变更
该动作不会检出拉取请求代码、在运行时调用大型语言模型或执行仓库脚本。
为何仅靠发现标识符是不够的
在 v0.2.0 版本中，代理门禁添加了稳定的发现标识符。
这为每个发现提供了一个简短的审计句柄，例如：
agf_987ab9ddb8c1b299
这对于引用、评论、未来的覆盖工作流以及基于日志的调试非常有用。
但标识符本身并非证明。如果某人日后看到该标识符，他们仍需知道是哪些记录材料生成了它。
v0.2.1 新增内容
v0.2.1 向公开发现添加了 evidenceSnapshot（证据快照）。
区分如下：
findingId = 简短的审计句柄
evidenceSnapshot = 用于推导该句柄的标准材料
该快照故意保持平淡无奇。它包含稳定的规则材料，例如：
- 规则标识符
- 严重程度
- 存在时的路径或行号
- 标准化的证据标签/值对
它不包含时间戳、报告顺序、风险评分、版本、提交散列值或可变的显示文本。
真实报告示例
紧凑日志输出示例：
代理门禁：需要人工决策
决策：警告
风险评分：49 / 100
原因：代理生成的拉取请求必须包含代理门禁合约。
建议下一步：在依赖范围检查之前添加拉取请求合约。
策略状态：当前为警告；调整后有资格成为合并门禁。
发现项：
- 错误 agf_be0c2c2a66312aff 合约/缺失
- 错误 agf_987ab9ddb8c1b299 风险/高风险路径 .github/workflows/agent-gate.yml
- 警告 agf_6016e753491255d7 工作流/危险模式 .github/workflows/agent-gate.yml
紧凑日志保持简短，但 JSON 和 Markdown 报告携带更完整的证据。
JSON 结构示例：
{
"findingId": "agf_987ab9ddb8c1b299",
"ruleId": "risk/high-risk-path",
"severity": "error",
"path": ".github/workflows/agent-gate.yml",
"evidenceSnapshot": {
"ruleId":
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
