Human-in-the-loop 实战：AI Agent 研发工作流的五道生产门禁
系列导读：本系列用一个可运行的 Spring Boot 秒杀 Demo，拆解“当 AI 成为我的全职下属”之后，研发工作流应该如何重建。五期内容从一次超卖事故开始，依次讨论并发正确性、上下文裁剪、防作弊 CI、Agent 友好架构和 Human-in-the-loop 上线门禁。主线不是证明 AI 能不能写代码，而是回答一个更实际的问题：当 Agent 已经能高吞吐地产出代码时，工程师如何用边界、验证和审批机制，把它变成可靠的执行者。
文章目录
- Human-in-the-loop 实战：AI Agent 研发工作流的五道生产门禁
-
- 1. 问题现场：Agent 能跑完整流程，为什么仍不能直接发布？
- 2. 适用对象
- 3. 原因：执行能力下降了成本，也放大了错误
-
- 第一门：需求必须可验证
- 第二门：上下文按依赖提供
- 第三门：限制可修改范围
- 第四门：自动化验证先于人工 Review
- 第五门：人类签署高风险决策
- 4. 原理：Human-in-the-loop 是责任边界，不是人工兜底
- 5. Demo 中的完整工作流
-
- 5.1 最小闭环验证
- 6. 解决办法：四类常见翻车及对应防线
- 7. 团队任务模板
- 8. 工程师的价值发生了什么变化
- 9. 最终检查清单
- 实验环境
- 小结
-
- 落地限制
- 测试 Demo 仓库
1. 问题现场：Agent 能跑完整流程，为什么仍不能直接发布？
AI Agent 可以读取 Issue、修改代码、运行测试并生成提交。看起来它已经覆盖了一个开发者从接需求到交付的完整链路。
真正危险的是下一步：如果它也能自己解释风险、自己修改验收标准、自己决定上线窗口，那么“自动化开发”会变成“自动化放大事故”。
本文把前四期的秒杀事故、上下文裁剪、防作弊审计和模块化架构组合成一条可落地的 Human-in-the-loop 流水线，并给出团队可以直接采用的任务模板和发布检查清单。
2. 适用对象
本文面向正在把代码 Agent 接入 Java 团队的技术负责人和高级开发者。
3. 原因：执行能力下降了成本，也放大了错误
推荐把流程拆成五道门：
需求门 -> 上下文门 -> 实现门 -> 验证门 -> 发布门
这五道门的核心不是拖慢 Agent，而是把“生成代码”放回工程系统：任务目标要可验证，上下文要可解释，修改范围要可控，验证标准不能由执行者单方面改变，高风险决策必须由人类签字。
第一门：需求必须可验证
错误写法：
优化秒杀接口，注意高并发。
可执行写法：
初始库存 100，300 个并发请求：
– 成功订单恰好 100；
– 最终库存为 0；
– 订单和库存事务一致；
– 禁止修改或跳过核心测试。
任务定义者需要把“业务正确”翻译成机器可判断的不变量。
第二门：上下文按依赖提供
使用 context_pruner.py 从目标类构建有限依赖包：
python ai_firm\\context_pruner.py `
—target src\\main\\java\\com\\xiaoz\\seckill\\service\\AtomicSeckillService.java `
—output reports\\context.json
上下文包应记录来源、选择原因和文件哈希。不要允许 Agent 自行遍历所有敏感配置和历史资料。
第三门：限制可修改范围
Developer Agent 只允许修改 src/main/java，QA Agent 只允许增加测试，二者都不能修改 pipeline。Demo 中的人设配置直接记录允许和禁止路径：
{
"role": "Developer Agent",
"allowed_paths": ["src/main/java"],
"forbidden_paths": ["src/test", "pipeline"]
}
第四门：自动化验证先于人工 Review
建议顺序：
python pipeline\\verify_integrity.py
python –m unittest discover –s ai_firm\\tests –v
mvn.cmd test
自动化先过滤明显违规、编译错误和并发不变量失败。人类不应把时间浪费在机器可以确定拒绝的提交上。
第五门：人类签署高风险决策
以下内容不应只由 Agent 决定：
- 数据库迁移和不可逆数据操作。
- 认证、支付、资金和隐私逻辑。
- 新增外部依赖和许可证风险。
- 生产环境配置、权限和发布窗口。
- 性能数据的解释与容量承诺。
4. 原理：Human-in-the-loop 是责任边界，不是人工兜底
Human-in-the-loop 不是每一行代码都让人重新写一遍，而是把人放在三个位置：
Agent 负责高吞吐执行，自动化负责确定性拦截，人类负责不可外包的判断。
5. Demo 中的完整工作流
运行本地“AI 公司”编排器：
python ai_firm\\start_firm.py —issue issue.txt
它会读取 Issue、构建上下文、执行完整性扫描，并生成报告：
{
"context_file_count": 4,
"context_character_count": 3427,
"integrity_passed": true,
"next_action": "review implementation and run mvn test"
}
这个脚本没有调用商业大模型 API，因此可以离线运行。生产环境可以在“生成上下文”和“完整性审计”之间接入任意 Agent 平台，但两侧门禁不应随模型供应商变化。
5.1 最小闭环验证
python pipeline\\verify_integrity.py
python –m unittest discover –s ai_firm\\tests –v
mvn.cmd test
本轮验证结果：Python 2 项测试通过；Maven 1 项并发测试通过；300 个请求争抢 100 件库存时，成功订单恰好 100、最终库存为 0。这个结果证明 Demo 的原子模式守住了当前测试定义的不变量，但不等价于生产容量认证。
6. 解决办法：四类常见翻车及对应防线
| 幽灵依赖 | 引入不存在或不必要的包 | Maven Enforcer、依赖白名单、许可证扫描 |
| 虚假成功 | 吞异常、返回空对象 | 禁止空 catch、错误指标、失败注入 |
| 测试作弊 | 跳过测试、万能断言 | 只读测试集、静态审计、CODEOWNERS |
| 范围蔓延 | 修 A 时顺手改 B | 路径权限、上下文裁剪、变更行数阈值 |
7. 团队任务模板
# 任务目标
一句话说明要改变的业务结果。
# 允许修改
– src/main/java/com/example/order/**
# 禁止修改
– pipeline/**
– src/test/resources/contracts/**
# 输入上下文
– 目标文件及依赖清单
– 接口契约
– 数据库约束
# 验收标准
– 功能断言
– 并发/性能边界
– 回滚条件
# 人工审批点
– 数据库迁移
– 新增依赖
– 生产发布
8. 工程师的价值发生了什么变化
当生成一段代码越来越便宜，价值不会消失，而会迁移到以下能力：
9. 最终检查清单
在接受 Agent 提交前逐项确认：
- Issue 包含量化验收条件。
- 上下文来源可追踪，没有无关敏感文件。
- 变更未越过允许路径。
- 没有跳过测试、万能断言和吞异常。
- 核心业务不变量有并发测试。
- 新依赖经过版本、漏洞和许可证检查。
- 性能数字来自当前版本的真实环境。
- 高风险变更有人类审批和回滚方案。
实验环境
| 验证日期 | 2026-06-15 |
| JDK | 17.0.15 |
| Spring Boot | 3.5.15 |
| MyBatis-Plus | 3.5.15 |
| Python | 3.12.5 |
| 验证范围 | Maven 与 Python 测试通过；Redis 门禁为可选路径，本轮未做网络实测 |
小结
这五期从一段会超卖的事务代码开始，最终形成了一条可执行的研发链路。结论不是“AI 会取代工程师”，也不是“AI 不可靠所以不能使用”，而是：
把 Agent 当作高吞吐但需要边界的执行者；把人类留在问题定义、系统设计和风险决策的位置。
代码会越来越便宜，可靠性不会。真正的下一代工作流，是让生成能力进入工程体系，而不是让工程体系为生成能力让路。
落地限制
- 路径白名单需要由实际执行平台强制，JSON 配置本身不具备权限隔离能力。
- 私有代码发送到外部模型前必须完成数据分级、脱敏和供应商合规评估。
- 自动门禁只能减少已知风险，生产发布仍需要监控、灰度、回滚和责任人确认。
测试 Demo 仓库
配套 Demo 仓库地址：https://github.com/quan020406/xiaozhan-blog-column-demos
上一篇：面向 AI Agent 的 Java 架构 系列起点：Spring Boot 高并发秒杀：AI Agent 的第一次超卖事故
完结撒花！！！：本系列到这里就告一段落了，咱们下个系列见
感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！ 
