云软件工厂的构建从来不是把几个独立代理拼在一起而是让它们形成能相互喂养、持续强化的闭环。前两步解决完问题 triage 和规格编写后代码审查自然成为第三环——它既是质量最后的守门人也是最容易把团队隐性经验埋没的环节。起初我以为只要把审查维度写得足够详细一份静态提示词就能让代理稳定输出高质量反馈。后来看到完整设计才发现真正决定长期效果的是把每一次人类纠正都变成可执行的技能更新而不是让提示词越堆越厚。代码审查技能让代理拥有完整执行上下文技能的核心输入只有三样PR 描述、代码 diff以及上游规格代理产出的规格文档如果有。输出则强制为结构化的review.json方便后续自动化处理成 GitHub 评论。技能指令里不仅列出安全、正确性、风格等审查维度还要求代理在提出任何修改建议前必须先用自身能力去验证——读取文件、搜索代码库、尝试构建、运行测试。这一步把审查从“意见输出”变成了“带证据的判断”。为了避免代理现场写脚本带来的 token 浪费和不确定性技能会把常用逻辑打包成 Python 辅助脚本作为资源随同加载。这些脚本负责 diff 解析、临时验证环境搭建、结果结构化等重复性工作让整个过程更确定、更省钱。{pr_summary:本次变更主要优化了 HTTP 请求处理潜在风险集中在超时与错误重试逻辑。,inline_comments:[{path:src/http/client.py,line:87,severity:important,message:缺少超时设置在网络抖动时可能导致请求挂起。,suggestion:建议添加 timeout 参数并与规格中的可靠性要求对齐。}],overall_recommendation:approve_with_comments}# 概念重构辅助验证脚本示例实际部署时会更完整defvalidate_suggestion(temp_branch,suggested_patch):# 1. 将建议变更应用到临时分支apply_patch(temp_branch,suggested_patch)# 2. 执行构建与关键测试build_resultrun_build(temp_branch)test_resultrun_tests(temp_branch)# 3. 返回结构化验证结论供审查代理引用return{build_success:build_result.success,test_passed:test_result.passed,logs:build_result.logstest_result.logs}GitHub Actions 集成安全可靠的触发与反馈闭环技能需要被可靠触发。GitHub Action 监听 PR 打开、同步、评论回复等事件收集上下文后启动云端代理执行审查。关键的安全设计是代理只拿到只读权限实际把review.json转成 GitHub 评论的工作由 Action 完成。这样既避免了提示注入风险代理无法跨 PR 操作或删除内容又保留了完整审计链路。当开发者回复评论并推送新代码时流程会自动重跑审查代理能读取之前的评论线程实现上下文连贯的增量审查。这让交互体验接近真实的人工 review 流程。外循环改进代理把人类反馈变成持久能力单纯的审查技能缺少仓库特有的“味道”——团队对错误处理的偏好、某些模块的历史坑点、验证建议时必须检查的额外条件。这些信息不可能一次性写进提示词。解决方案是一个每日运行的外循环改进代理。它会把当天所有审查记录 人类对评论的回复纠正或确认全部拉出来综合分析。如果发现值得固化的新知识就自动发起 PR 更新审查技能文件。下一次审查代理运行时就带着这些新学到的规则上岗。这个机制把零散的人类智慧转化成了结构化、持久的系统资产。久而久之审查质量会越来越贴合团队真实实践而不是泛泛而谈的通用建议。外循环代理就像团队里那位总在周末复盘所有 review 的资深架构师它不只是记录问题而是把“这次为什么这个建议被接受/拒绝”的原因提炼出来写进团队的审查手册里。自改进循环的完整协作流程整个系统形成了一个闭环PR日常流程是否PR提交或代码更新代码审查代理执行技能输出review.json → GitHub评论开发者回复或修正每日触发外循环改进代理分析所有审查记录与人类反馈发现值得固化的新知识?自动创建PR更新审查技能下次审查使用进化后技能保持当前技能继续运行不同审查方案的真实权衡评估维度传统人工审查静态AI代理审查自改进代码审查代理审查一致性高度依赖个人固定但易过时随真实反馈持续提升团队隐性知识沉淀零散难以系统化几乎为零自动提炼并持久化到技能中人力长期投入高reviewer 疲劳低初始配置后极低对特定代码库适配需长期培训通用但针对性弱通过外循环自动学习团队规范建议可验证性主观判断可能缺乏执行验证可主动构建、测试后再建议长期演进能力缓慢迭代基本停滞持续从真实交互中进化从表中能看到自改进方案在长期维度上优势明显但它要求前期把技能框架和外循环逻辑设计好。一旦跑起来维护成本远低于反复人工介入或不断调优静态提示词。起初我担心外循环会让技能提示词膨胀成难以维护的巨兽但设计里强调“值得记住”的筛选机制而不是简单追加原始反馈。这要求外循环代理本身具备良好的提炼能力只保留能真正提升未来审查质量的洞察。在生产环境落地前建议从小仓库开始试点重点监控两个指标审查代理被人类纠正的频率以及外循环提出的更新被采纳的比例。这两个数据能最直观地告诉你系统是否在真正进化而不是在自我安慰。随着AI代理逐步渗透整个软件开发生命周期那些能把反馈闭环设计成系统能力而非一次性提示的团队将在效率和质量上建立起真正的护城河。代码审查不再只是质量关卡而是组织学习能力的放大器。如果你已经在自己的仓库里尝试类似代理工作流欢迎分享你在反馈循环设计上遇到的具体工程挑战。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
