不会还有人既当运动员又当裁判吧？审核门禁必须分角色 | 主 Agent 与审核

上一篇不会还有人每个会话都从零发明流程吧入口文件才是值班手册 | Agent 启动清单不会还有人既当运动员又当裁判吧审核门禁必须分角色 | 主 Agent 与审核系列《从 Rule 到落地AI 工程化实践》第 17 篇标签Agent · 多角色 · 审核门禁 · 协作专栏从小白到AI落地大师序言单 Agent 能干活但忙起来容易既当运动员又当裁判。童鞋们可能见过同一个角色改完自己审高风险合并一路绿灯。本篇讲主 Agent、子任务 Worker、审核门禁的三角职责。强调责任边界不是堆更多模型调用炫技。说句自嘲的我试过「一个超级 Agent 包办一切」上下文打架标准漂移出错时还找不到该骂谁。分角色之后不是更慢了是更少返工了。记住一句话主 Agent 管目标Worker 管改动审核门禁管放行——批的权和写的权永远不在同一双手里。本篇用一份roles_gate.py把这句话算出来风险打分、权限矩阵、契约边界三合一四个场景各砍一刀输出真实跑过。概念主 Agent对用户目标负责澄清、委派、汇总。Worker窄上下文、短生命周期的执行角色。审核门禁对照 Rule 批准或打回不亲自实现。契约子任务明确的输入输出与权限边界。可以理解为主厨点菜与统筹厨师按菜谱做质检只尝不炒。质检若自己下场炒菜餐厅就只剩表演赛了。三角关系画成一张图onboarding 贴这张就行下发契约下发契约交付物交付物approvereject rule_ref用户目标主 Agent澄清 / 拆分 / 汇总Worker A只读调研Worker B窄范围改动审核门禁只审不写问题在哪单 Agent 瓶颈上下文打架既写又审标准会被「好不容易改完了」绑架。并行无纪律时两个 Worker 写同一文件合并现场像抛硬币。失败归属不清子任务挂了整单是重试、降级还是中止不写明现场靠吵。举例角色契约示意roles:main:{can:[plan,delegate,summarize],cannot:[bypass_gate]}worker:{can:[edit_in_scope],cannot:[change_rules]}reviewer:{can:[approve,request_changes],cannot:[implement]}把 can / cannot 拉成一张权限矩阵评审时逐行勾比读 YAML 直观动作主 AgentWorker审核门禁拆任务 / 下契约✅❌❌改业务代码❌✅限契约范围❌改 Rule / 门禁配置❌❌❌走独立 PRapprove / reject❌❌✅要求补测❌❌✅绕过门禁合并❌❌❌门禁触发不能停在「风险高就过审」的口号上权限也不能停在「应该不会越界吧」的默契上——两样都得能算。下面一份roles_gate.py纯标准库、复制即跑把风险打分、权限矩阵、契约校验三样合一。子任务契约记得结构化成 JSON对应代码里的Contract机器可校验、可归档别写散文{task_id:T-1024,goal:修 escape 解析,in:{files_allowed:[adaptor/parse/],read_only:[docs/]},out:{deliverable:diff,tests_required:[adapt_smoke_01]},forbidden:[change_rules,touch_security],correlation_id:run-2026-10-13-b7}完整可跑roles_gate.py# roles_gate.py —— 三角色权限矩阵 风险门禁 契约校验纯标准库可跑# 用法python roles_gate.pyfromdataclassesimportdataclass# —— 风险打分命中高危路径给基础分再按改动量与文件类型加权 ——HIGH_RISK_PFX(security/,migrations/,prod/)dataclassclassDiff:files:listlines:inttouches_config:boolFalsedefrisk_score(d:Diff)-int:base10ifany(f.startswith(HIGH_RISK_PFX)forfind.files)else0size3ifd.lines50else(1ifd.lines10else0)kind2ifd.touches_configelse0returnbasesizekinddefgate(d:Diff)-str:srisk_score(d)ifs10:returndeny_until_review# 命中高危必须过审ifs3:returnconfirm_then_merge# 中等确认后放行returnauto_pass# 低风险直通# —— 权限矩阵动作是否属于该角色越界即拒 ——ALLOW{main:{plan,delegate,summarize},worker:{edit_in_scope},reviewer:{approve,request_changes},}defenforce(role:str,action:str)-str:returnOKifactioninALLOW[role]elseDENY# —— 子任务契约允许路径 禁止动作越界整单打回 ——dataclassclassContract:files_allowed:listforbidden:listdefcheck_contract(c:Contract,d:Diff)-list:v[f越界改文件{f}forfind.filesifnotany(f.startswith(p)forpinc.files_allowed)]returnvdefmain():print( 场景1低风险直通 )d1Diff([adaptor/parse/tail.py],lines5)print(f{d1.files}({d1.lines}) - risk{risk_score(d1)}decision{gate(d1)})print(\n 场景2命中高危路径必须过审审写分离)d2Diff([security/auth.py,adaptor/parse/x.py],lines60)print(f{d2.files}({d2.lines}) - risk{risk_score(d2)}decision{gate(d2)})print(f reviewer approve -{enforce(reviewer,approve)}审核者有权批)print(f worker approve -{enforce(worker,approve)}实现者无权自审)print(f reviewer edit -{enforce(reviewer,edit_in_scope)}审核者只审不写)print(\n 场景3主 Agent 想绕过门禁 )print(f main bypass_gate -{enforce(main,bypass_gate)}没有任何角色握有 bypass)print(\n 场景4子任务越界整单打回 )cContract(files_allowed[adaptor/parse/],forbidden[change_rules])d4Diff([adaptor/parse/x.py,docs/notes.md],lines8)vcheck_contract(c,d4)print(f contract.files_allowed{c.files_allowed})print(f worker 交付{d4.files})print(f violations{v})print(f decision{rejectifvelsegate(d4)}rule_refcontract#files-allowed)if__name____main__:main()三块逻辑各司其职gate()按风险分档enforce()查权限矩阵就是上面那张表的代码化check_contract()卡越界。四个场景一次跑全python roles_gate.py真实输出原样贴上 场景1低风险直通 [adaptor/parse/tail.py] (5) - risk0 decisionauto_pass 场景2命中高危路径必须过审审写分离 [security/auth.py, adaptor/parse/x.py] (60) - risk13 decisiondeny_until_review reviewer approve - OK审核者有权批 worker approve - DENY实现者无权自审 reviewer edit - DENY审核者只审不写 场景3主 Agent 想绕过门禁 main bypass_gate - DENY没有任何角色握有 bypass 场景4子任务越界整单打回 contract.files_allowed[adaptor/parse/] worker 交付 [adaptor/parse/x.py, docs/notes.md] violations[越界改文件 docs/notes.md] decisionreject rule_refcontract#files-allowed输出你看什么逐行拆四个场景正好把「批的权与写的权分开」演成代码场景1 低风险直通adaptor/parse/tail.py改 5 行risk0 →auto_pass。门禁不是什么都拦——把 90% 低风险放过去才腾得出人力盯剩下的 10%。场景2 一刀三响命中security/前缀base10 加 size3risk13 →deny_until_review。更有意思的是紧接三行权限判定reviewer approve - OK、worker approve - DENY、reviewer edit - DENY。同一个高危 diff批的权力只给审核者写补丁的权力审核者恰恰没有——审写分离不是口号是enforce查ALLOW表查出来的。谁想「好不容易改完了顺手自审自过」代码当场说不。场景3 没有旁路主 Agent 想bypass_gate→DENY因为bypass_gate不在任何角色的允许集里。这句话落地成代码就是本篇命门可绕过的门禁是门贴。分数阈值可以演进「谁能批」这条底线不能。场景4 契约硬边界Worker 交付里混进docs/notes.md不在files_allowed[adaptor/parse/]内 →violations[越界改文件 docs/notes.md]→ 整单reject还带回rule_ref。不谈「顺手帮个忙」越界即打回——而且这行结构化decision rule_ref正是第 19 篇记忆层能直接回收的干净原料。分数线是拍的但拍出来的分数线也能演进——每周看一次「confirm 放行的后来返工没」返工多就调阈值。最怕的不是阈值不准是没有阈值没有gate()那一行deny_until_review就永远停在「大家觉得风险高」。契约里forbidden一栏是硬边界越界即整单打回。并行与串行只读调研可并行写同一文件必须串行。失败上抛策略写清何时中止整单何时换 Worker 重试。审核者要求补测的权力要硬——没有补测就合并审核只是装饰画。自检# 多角色自检 - [ ] 是否设计了主/子/审三角职责 - [ ] 审核者是否「只审不写」 - [ ] 子任务是否有输入输出契约 - [ ] 写同一文件是否禁止并行 - [ ] 失败上抛与中止条件是否写明两问。第一审核角色有没有实现权限有就还没分开。第二主 Agent 能否绕过门禁能绕过的门禁是门贴。三角职责画进 onboarding 图比写成长文有效。新人第一眼看到「审者不写」文化就半成了。并行不是效率美德。只有契约清晰的只读调研才值得并行写路径并行常常是把冲突推迟到更贵的时刻。多角色最低配是两人主 Agent 只负责改与提议审核 Agent 只负责对照 Rule/清单放行或打回不写业务补丁。审写不分的结局很固定自己给自己开绿灯还觉得流程很完整。交接时带上correlation_id与变更摘要。审核不看长篇聊天只看交付物与门禁结果。审核门禁的输出建议枚举approve/reject/need_info。拒绝必须带条款编号来自 Rule需要信息必须列出缺失字段。禁止「感觉不太好」式驳回——不可判定的审核会逼主 Agent 改去旁路。若人手不足审核可以是第二个模型会话但规则相同只读交付物与清单不写补丁。模型审模型可以审写合一不行。读到这里不妨立刻做一个五分钟动作打开你们仓库找到与本篇对应的那个目录没有就新建把文中最小示意落成真实文件名。文件在讨论才有坐标文件不在下周还会从「我们觉得」开始。第 17 篇的验收不是「读完」是「仓库里多了一份可指出的东西」。举例加长审核回传模板decision: reject rule_ref: hard-constraints.md#forbid-public-entry need: 用户点名路径的确认截图 / 或缩小 diff correlation_id: ...主 Agent 只准根据 need 补齐不准边改边自我 approve。思考小结三句。分角色是为了责任清晰不是为了堆更多模型调用。审核者不应同时是实现者。契约化输入输出让子任务可测可替。可以理解为厨、灶、质检分岗菜品才稳。下篇进入本地记忆层——蒸馏什么、不蒸馏什么聊天记录不等于组织记忆。下篇预告《为什么要本地记忆层蒸馏什么、不蒸馏什么》——噪声和密钥一起进库比遗忘还可怕。觉得有用的话欢迎点赞、留言聊聊你们审写是否分离有「自己改自己合并」的惊魂史也欢迎对照三角拆。专栏从小白到AI落地大师《从 Rule 到落地AI 工程化实践》