【系统架构设计】AI 原生开发流程：人机协同的架构实践

Part XV 前三篇分别钉住三块积木：101 系统约束、102 流水线兜底、103 可读上下文。缺了第四块，组织仍会在日常里打架：谁可以让 Agent 改什么、何时必须人点头、出事算谁的。

本文收束 Part XV：把人机分工、评审门槛与生产变更门禁编成 可审计流程。Agent 身份、委托链与工具级授权细节见 agent-identity，尤其 Human-in-the-Loop；LLM 作为在线依赖见 95。本文不写提示词技巧，不写法律意见——只写架构师能落地的责任面与状态机。

系列导航： ← 架构即 AI 上下文 · 系统架构设计索引 · Part XIV 不变量

相关专题： 康威定律 · ADR · SLO · agent-identity 落地架构

一、问题：吞吐上升之后，流程必须显式

1.1 隐式流程的破产

人写代码时代，许多团队靠隐式规范运转：资深审关键路径、新人改边角、生产变更走口头协调。AI 把「边角」与「关键」的边界模糊化——一次会话可以同时改 API、策略与迁移脚本。隐式流程的破产信号包括：

• 合并记录里无法回答「这段 diff 是否经人审」；
• Agent 使用的身份与个人身份混用，审计归因断裂；
• 回滚时找不到「谁批准放宽策略」。

Conway 定律指出组织沟通结构映射到系统结构[1]；AI 协作者加入后，若组织 没有 对应的沟通与批准结构，映射结果是任意的——通常表现为权限过大的默认路径。

1.2 本文核心问题

1. 人机角色与责任面如何划分，才能既保吞吐又保审计？
2. PR/生产变更的状态机应包含哪些硬门禁？
3. 如何与 101–103、agent-identity HITL 组合，而不是另起一套口号？
4. 责任归属争论停在哪条可辩护边界？

二、角色与责任面

2.1 角色

2.2 责任面（架构表达）

用三句话固定责任，避免事后扯皮：

1. 机器可判定项 未绿，不得进入人审队列（节省人眼）；
2. 人审签字 覆盖「意图与风险接受」，不覆盖「保证无缺陷」；
3. 生产事故 归因到 批准路径与身份，而不是「模型名字」——模型是工具；批准合并与放行发布的主体进入审计日志。

这与 agent-identity 的归因字段要求一致：哪个用户委托的哪个 Agent 做了什么[2]。开发期流程应复用同一归因思想：PR 元数据记录 generator=agent|human、approver=、policy_diff=。

三、PR 与生产变更状态机

3.1 开发期（PR）

stateDiagram-v2
  [*] --> Draft: Agent_or_human_opens_PR
  Draft --> CI_Running: push
  CI_Running --> CI_Failed: hard_gate_red
  CI_Failed --> Draft: fix
  CI_Running --> Awaiting_Risk_Class: hard_gates_green
  Awaiting_Risk_Class --> Auto_Merge_Candidate: low_risk_policy
  Awaiting_Risk_Class --> Human_Review: high_risk_or_policy_widen
  Human_Review --> Changes_Requested: reject_or_ask
  Changes_Requested --> Draft: update
  Human_Review --> Approved: approve
  Auto_Merge_Candidate --> Approved: optional_light_review
  Approved --> Merged: merge
  Merged --> [*]

风险分级（与 101/102 同一尺子——副作用不可逆性）：

「为过测而删测试/放宽 schema」一律升为高风险。

3.2 生产期（发布）

stateDiagram-v2
  [*] --> Artifact_Ready: merge_builds_artifact
  Artifact_Ready --> Canary: progressive_rollout
  Canary --> Rolled_Back: SLI_breach
  Canary --> Full_Rollout: SLI_ok
  Rolled_Back --> [*]
  Full_Rollout --> [*]
  Artifact_Ready --> Blocked: error_budget_exhausted
  Blocked --> [*]

错误预算耗尽时冻结常规发布，见 28。AI 高频合并更需要这条冻结，否则 canary 永远在烧预算。

3.3 与 HITL 的衔接

运行中 Agent（客服改库、运维执行）的高风险步骤，用 agent-identity/05 的同步确认或异步审批。开发期 HITL 的对应物就是上表「高风险人审」与生产「发布窗口批准」。不要把两种 HITL 混成一个按钮：一个挡 工具副作用，一个挡 代码进入主干/生产。

四、与 101–103 的组合装配

装配反模式：

• 只有 chatbot，没有门禁 → 101/102 空转；
• 只有门禁，没有上下文 → 高通量错误补丁；
• 只有文档，没有责任面 → 出事无批准主体。

落地参考架构可与 agent-identity/10 对齐：IdP + 策略引擎 + Agent 网关；开发期再加 必填 CI + CODEOWNERS + 发布控制器。

五、争论：责任归属

5.1 双方常见主张

5.2 架构可辩护边界

在工程上可辩护、且与审计字段对齐的划分是：

1. 平台责任：未提供或绕过可提供的硬约束（无契约校验、默认 admin、无可归因日志）导致的事故面；
2. 批准者责任：在绿灯之后仍接受的高风险意图（放宽策略、破坏性迁移）；
3. 模型提供方：按其服务条款与缺陷披露流程处理模型层问题；不替代部署方的权限与门禁设计。

本站不提供法律责任结论；上表是 系统设计时的归因面，便于事后复盘写清「控制措施在哪一层缺失」。开放监管框架随司法辖区变化，工程上以 可证明的控制措施 为稳妥策略。

六、开放问题

1. 多 Agent 协作变更的合并语义
   两个 Agent 并行改同一契约时，三方合并与意图冲突缺少标准协议（对比多人协作已有 Git 语义，但意图层无）。

2. 自动晋升文档写回
   Agent 是否可以在合并后自动开「文档同步 PR」仍争议；与 103 开放问题相同，需人审晋升以免污染 SSOT。

3. 跨组织 Agent
   供应商 Agent 提交 PR 时，委托链与责任面如何映射到内部 CODEOWNERS——身份模型见 agent-identity，流程模板仍不统一。

七、Part XV 收束

与 100 不变量 的关系：Part XV 不推翻不变量，而是在「变更作者包含 AI」的前提下，把爆炸半径、反馈控制与可观测前提 操作化。

落地检查清单

1. PR 是否记录生成者/批准者/策略是否放宽？
2. 高风险路径是否强制指定 owner，而非任意一人？
3. CI 未绿是否无法进入人审？
4. 生产是否有 canary + 错误预算冻结？
5. 运行中 HITL 与开发期人审是否分开建模？
6. 事故复盘是否能指出缺失的是约束、门禁、上下文还是批准？

参考资料

经典与工程文献

• Conway, M. E., “How Do Committees Invent?” Datamation, 1968.（A 级）[1]
• Beyer, B. et al., Site Reliability Engineering — 变更管理。（B 级）
• Humble, J., Farley, D., Continuous Delivery.（B 级）

站内交叉

• 101 · 102 · 103
• agent-identity 索引 · HITL · 落地架构[2]
• 84 康威定律
• 95 AI 原生架构
• 100 不变量

规范（边界）

• RFC 8693 OAuth 2.0 Token Exchange（委托表达；细节见 agent-identity）。（A 级）
• MCP Specification（草案状态须标注版本；细节见 agent-identity）。（A/B 级，draft）

核心文献（本主题）

实验与数据

• 本篇状态机为规范示意；不报告未统计的人审耗时或缺陷率。

系列导航： ← 架构即 AI 上下文 · 系统架构设计索引 · 架构的不变量