如果你最近也在折腾 AI 辅助开发大概率会遇到一种情况单个大模型已经很聪明但让它从头到尾独立完成一个完整需求时结果总是不稳定。要么前面需求理解偏了后面代码越写越歪要么生成结果没人检查把边界条件写错也没人提醒。这篇文章想聊的正是把“一个大模型干活”升级成“四个 Agent 分工协作”的一套最小实现方案。“我们四个真是太厉害了”——这句话放在技术语境里可以理解成一种很实用的工程范式四个分工明确的 Agent像四人小组一样分别负责需求拆解、方案分析、代码生成和代码评审通过一套简单的协作流程把复杂任务跑完。单个 Agent 的能力没有变强但系统整体输出的稳定性和可维护性会上一个台阶。本文会从多 Agent 协作的原理讲起给出一个完整可运行的 Python 示例并拆解日常接入时的常见问题和工程建议。如果你正在做 AI 相关的工具链、想把 LLM 接入真实业务流程或者只是对“多 Agent 到底怎么落地”感兴趣这篇文章会直接给你一套可以核对的参考实现。我们不只谈概念还会把代码、运行方式、判断标准、排错路径都展开讲清楚。读完以后你可以直接把这个最小示例改造成自己项目里的协作框架。1. 这篇文章真正要解决的问题先聊一个很现实的开发痛点。以前用 LLM 做代码生成最常见的用法是打开一个对话窗口把需求粘贴进去让模型一次性输出完整代码。需求简单时效率确实高但需求一旦超过 200 行或者涉及多个模块、多步修改问题就来了。第一个问题是上下文不可控。对话轮数越多模型越容易“忘掉”最开始的需求约束。很多人在第 5 轮对话时发现模型开始偏离原始需求本质原因不是模型不够聪明而是没有把“需求、方案、实现、评审”这几个阶段拆开所有信息混在一个上下文里互相干扰。第二个问题是缺乏检查机制。单个 Agent 生成代码后没有第二双眼睛做评审。你让模型写一个带缓存的斐波那契函数它可能写得对但让它写一个涉及权限校验的支付接口它很可能忽略空值判断、超出额度校验这些边界条件。问题不在生成而在缺少一道“关卡”。第三个问题是无法工程化。当你需要把 LLM 嵌入到 CI/CD、自动化测试、需求管理、代码仓库这些系统里时你需要的不是一个会聊天的大模型而是一个可编排、可重试、可审计的工作流。每个步骤都要有输入、输出、状态记录。多 Agent 协作解决的就是这些问题。它的核心思想不是让模型更强而是把一个大而全的任务拆成多个小而专的子任务每个子任务由一个 Agent 负责Agent 之间通过明确的输入输出衔接。这种模式在架构上更接近真实软件团队的运转方式业务方提需求架构师做方案开发写代码测试和评审把关。从这个角度看本文最值得读的读者有两类。第一类是正在做 AI 应用工程化的开发者你想知道多个 Agent 之间到底怎么配合、怎么传数据、怎么避免循环。第二类是技术负责人或架构师你想评估这套模式是否值得引入团队它真正的成本在哪里。上面两类读者都能从这篇文章里拿到可落地的东西。2. 多 Agent 协作的核心概念与适用场景2.1 什么是 Agent、Task 与协作流程在大型语言模型的应用里Agent 不是一个绝对精确的术语。最简单理解是一个 Agent 就是一个“有角色的 LLM 调用单元”它包含三样东西角色设定、任务输入、输出格式。角色设定决定了这个 Agent 怎么思考。比如“你是一名严谨的后端开发工程师”“你是一名负责代码评审的资深工程师”这些 system prompt 就是角色的灵魂。任务输入是这个 Agent 拿到的具体材料。输出格式则决定了结果能否被下游使用比如“只输出 JSON”“只输出代码不要解释”。Task 是 Agent 要完成的某个具体工作单元。一个复杂需求通常被拆成多个 Task这些 Task 之间会有依赖关系。协作流程就是这些 Task 的执行路径谁先执行谁后执行结果怎么流转失败后怎么处理。图上的“多 Agent 协作”本质上就是“有向的任务依赖图”。2.2 四人角色模型需求、分析、编码、评审本文的最小示例采用四个角色分别对应软件开发中最常见的四个阶段。需求 Agent 负责把原始需求整理成结构化文档。为什么要单独拆一步因为用户的需求往往是模糊的比如“实现一个带缓存的斐波那契函数”这里面其实包含了很多隐含信息是否要求递归缓存是用函数装饰器还是手动字典输入参数异常时怎么处理需求 Agent 要做的是把这些模糊点变成明确的功能清单和验收标准。分析 Agent 基于需求文档输出实现方案。这一层解决的是“怎么实现”的问题。对于小型需求来说方案不一定很复杂但它要列出算法思路、边界条件、测试用例。有了这层分析编码 Agent 的生成质量会明显更稳定因为它不再是凭空生成代码而是有明确的实现路线。编码 Agent 是负责产出最终代码的角色。它的输入是需求文档和实现方案输出是完整可运行的代码文件。这里的关键约束是“只输出代码”。如果它在代码里混入大段解释下游评审和后处理就会变得很难解析。评审 Agent 是质量关。它拿到需求文档、实现方案和代码从正确性、边界条件、代码规范、安全隐患四个维度做检查。如果发现问题输出具体修改建议如果通过输出 PASS。评审 Agent 是整个协作链路里最容易被忽略、却最值得投入的角色。2.3 多 Agent 与单 Agent 流程的对比对比维度单 Agent 一次生成多 Agent 分工协作上下文管理所有信息混在一个上下文越长越容易漂移每个 Agent 只关注自己阶段的关键信息上下文精简质量保障无独立检查生成完直接交付评审 Agent 独立把关发现问题进入修复循环可观测性只有最终结果过程不可回溯每个阶段都有产物中间状态可审计可替换性换模型等于改全流程单个 Agent 的模型或 Prompt 可以独立调整执行成本一次调用成本低多次调用成本更高需要控制循环轮次工程复杂度实现简单需要定义数据结构、流转规则、异常处理这个对比传达了一个重要判断多 Agent 协作更适合“流程重、质量要求高、需要审计”的场景不适合“一句话回答、一次性简单生成”的场景。如果你只是想让模型写一个 20 行的工具函数单 Agent 完全够用强行上多 Agent 反而增加成本和延迟。场景选错了框架再好也是负担。2.4 适合与不适合多 Agent 协作的场景先说适合的场景。第一类是代码生成与代码评审流程这是最典型的应用第二类是需求分析与方案设计需要通过多步推理将模糊需求变成可执行计划第三类是自动化测试生成先分析代码再产出测试用例再执行并反馈第四类是企业内部的工单处理流程不同 Agent 分别负责分类、检索、生成答复、复核。不适合的场景也值得说清楚。低延迟的实时聊天不适合因为多轮调用会显著增加响应时间。成本敏感的小任务不适合如果一个任务一次 LLM 调用就能完成拆成四次调用会造成明显浪费。强交互式的探索性任务也不适合比如让模型陪你头脑风暴这种场景更适合单 Agent 连续对话。判断一项任务是否适合多 Agent核心标准就两个是否存在可拆分的独立阶段以及每个阶段是否都需要独立的质量判断。3. 环境准备与基础配置在写代码之前先把运行环境准备好。本文的示例代码量不大对机器配置没有特殊要求重点在 Python 环境和依赖管理上。3.1 Python 版本与依赖管理推荐使用 Python 3.9 及以上版本代码中会用到类型注解和 f-string太旧的版本容易踩坑。如果你本机有多个 Python 版本建议先为项目创建一个独立的虚拟环境避免依赖冲突。创建虚拟环境和安装依赖的命令如下python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai python-dotenv这里用到的两个库openai是官方 SDK但它同样支持所有兼容 OpenAI 接口的模型网关很多企业内部部署的模型服务也会提供 OpenAI 兼容端点python-dotenv用于从.env文件加载配置避免把密钥硬编码在代码里。3.2 配置文件用一个 .env 管理模型访问为了不把模型地址和密钥写死在代码中我们在项目根目录创建.env文件。这里的写法是通用的占位方式实际值请根据你的模型服务网关填写。# 文件路径.env # 大模型服务地址如果走本地或企业内部网关请填写网关地址 LLM_BASE_URLhttp://localhost:8000/v1 # 模型名称以你网关中实际提供的模型名为准 LLM_MODELyour-model-name # 密钥本地不需要鉴权时可以留空生产环境必须通过环境变量注入 LLM_API_KEYnot-required需要注意这个.env文件不要提交到 Git 仓库。正确做法是把一个.env.example模板提交到仓库团队成员复制成自己的.env再填写。如果在生产环境部署更推荐通过容器编排平台或配置中心注入环境变量而不是使用.env文件。密钥管理遵循最小权限原则谁需要谁才持有不要在前后端代码里流转。这里的默认地址写的是本地模型网关主要考虑是很多开发团队会在内网部署统一的大模型服务让多个应用共用一个网关。如果你的环境使用云端官方接口只需把LLM_BASE_URL改成官方地址并填入真实密钥即可代码本身不需要改动。这样做的好处是代码与模型服务解耦后续切换模型只需要改配置不需要改代码。3.3 初始化项目结构本文的示例放在一个名为four-agents-demo的项目目录中。four-agents-demo/ ├── .env ├── agent.py ├── main.py └── workspace/其中agent.py定义 Agent 类和大模型调用函数main.py编排四个 Agent 的执行流程workspace目录保存中间产物。目录可以先手动创建也可以由主程序自动创建。看完下一节的核心流程再回头理解这两个文件会更容易。4. 核心流程拆解一个需求是怎么被“四个 Agent”跑通的本节用“实现一个带缓存的斐波那契函数”作为示例需求把四个 Agent 的分工串成一个完整的执行链路。理解了这个链路你就理解了多 Agent 协作的骨架。4.1 第一步需求 Agent 将模糊需求转成结构化文档原始需求是“实现一个带缓存的斐波那契函数输入 n返回第 n 个斐波那契数。”这个描述看起来清晰但实现前仍然有多个问题需要确认n 的范围是什么是否要考虑负数缓存是全局的还是局部的递归写法是否被允许需求 Agent 的任务就是把这些不确定项以提问或假设的方式写入需求文档。在最小示例里我们要求需求 Agent 输出一份 Markdown 文档内容包括功能概述、输入输出定义、约束条件、验收标准。这份文档后续会成为分析 Agent 和评审 Agent 的依据。这一步的产出文件是workspace/requirement.md。4.2 第二步分析 Agent 基于需求输出实现方案分析 Agent 拿到requirement.md后不需要重新理解原始需求只需要做方案设计。它会选择算法、定义数据结构、列出边界条件和测试用例。对于斐波那契这个需求方案可以很简单使用递归函数fib(n)用functools.lru_cache做缓存边界条件为n 0时抛出参数异常n 1或n 2时返回 1。这一步看起来简单但它非常关键——方案明确之后编码 Agent 不需要自己“猜”设计意图只需要把方案翻译成代码。这一步的产出文件是workspace/plan.md。4.3 第三步编码 Agent 生成可运行代码编码 Agent 的输入是需求文档和实现方案输出是一份 Python 代码文件。为了让下游评审解析方便系统提示词里要强调“只输出代码不要输出解释文字”。如果你的模型总是额外输出废话可以在后处理环节把 Markdown 代码块提取出来只保留代码部分。这里有一个工程上的取舍是否让编码 Agent 直接读两个文件在最小示例中我们把文件和任务文本一并传给模型。对于更复杂的项目建议把大文件先做摘要只把关键信息传给编码 Agent避免上下文被无关内容撑爆。这一步的产出文件是workspace/code.py。4.4 第四步评审 Agent 把关不通过则进入修复循环评审 Agent 是最后一个环节也是质量保障的关键。它同时拿到需求、方案和代码从正确性、边界条件、代码规范、安全隐患四个维度做检查。如果评审通过输出中会包含REVIEW_RESULT: PASS如果未通过输出中会包含详细的问题列表和修复建议同时包含REVIEW_RESULT: FAIL。主程序检测到 FAIL 后会把评审意见作为补充材料传给编码 Agent 重新生成代码最多循环 3 次。如果 3 次后仍未通过流程停止等待人工介入。这里为什么要限制循环次数因为 LLM 的调用有成本和延迟如果评审标准本身过于严苛或者需求本身存在问题Agent 可能陷入“改一个 bug 引入另一个 bug”的循环。设置上限是一种熔断机制保护系统不被无效迭代拖垮。4.5 整个流程的流转关系用文字描述这个流程如下原始需求 - 需求Agent - requirement.md requirement.md - 分析Agent - plan.md plan.md requirement.md - 编码Agent - code.py requirement.md plan.md code.py - 评审Agent 评审不通过 - 编码Agent 基于评审意见修复 - 再次评审 评审通过 - 输出最终结果从工程角度看这个流程是一个典型的“管道加循环”结构。四个 Agent 是管道上的处理节点workspace目录是节点间的消息队列而主程序是调度器。理解了这个抽象你就知道如何把四个 Agent 扩展成八个、十六个也可以把管道节点替换成外部工具调用。5. 完整代码实现最小可运行的多 Agent 协作示例下面进入最能落地的部分。我们用一个最小可运行示例把上一节的流程全部用代码实现出来。文件分为两个agent.py负责底层模型调用main.py负责编排与循环控制。5.1 agent.pyAgent 类与模型调用封装# 文件路径agent.py import os from openai import OpenAI # 使用环境变量配置模型网关代码不硬编码任何服务地址 def get_client(): return OpenAI( api_keyos.getenv(LLM_API_KEY, not-required), base_urlos.getenv(LLM_BASE_URL, http://localhost:8000/v1), ) class Agent: 一个 Agent 就是一个角色化的 LLM 调用单元。 def __init__(self, name: str, system_prompt: str, output_path: str None): self.name name self.system_prompt system_prompt self.output_path output_path def run(self, task_text: str, temperature: float 0.2) - str: client get_client() resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-name), messages[ {role: system, content: self.system_prompt}, {role: user, content: task_text}, ], temperaturetemperature, ) content resp.choices[0].message.content.strip() if self.output_path: os.makedirs(os.path.dirname(self.output_path), exist_okTrue) with open(self.output_path, w, encodingutf-8) as f: f.write(content) return content这段代码的核心有两个地方。第一get_client()全部从环境变量读取配置这样代码可以在不同环境间迁移。第二Agent.run()做的事情很纯粹拼消息、调模型、写产物文件。产物落盘是多 Agent 协作的重要实践每个阶段的结果都能被审计和回溯。5.2 main.py四个 Agent 的编排与修复循环# 文件路径main.py import os import re def get_agent_prompts() - list: 返回四个 Agent 的角色配置。 requirement_prompt ( 你是一名资深需求分析师。你的任务是把用户原始需求整理成结构化需求文档。\n 要求包含功能概述、输入输出定义、约束条件、验收标准。\n 请使用 Markdown 格式输出不要输出多余寒暄。 ) plan_prompt ( 你是一名系统架构师。基于需求文档输出可落地的实现方案。\n 方案必须包含算法选择、数据结构、边界条件、测试用例。\n 请使用 Markdown 格式输出。 ) coder_prompt ( 你是一名高级 Python 工程师。基于需求和方案输出完整代码。\n 只输出 Python 代码不要输出任何解释文字。\n 代码必须可以直接运行并处理明显的边界条件。 ) reviewer_prompt ( 你是一名资深代码评审专家。请从正确性、边界条件、代码规范、安全隐患四个维度评审代码。\n 如果代码通过评审请在最后一行输出 REVIEW_RESULT: PASS。\n 如果代码不通过请列出具体问题与修复建议并在最后一行输出 REVIEW_RESULT: FAIL。 ) prompts [ (需求Agent, requirement_prompt), (分析Agent, plan_prompt), (编码Agent, coder_prompt), (评审Agent, reviewer_prompt), ] return prompts def extract_code_from_markdown(text: str) - str: 如果模型返回了 Markdown 代码块只提取 Python 代码部分。 pattern r(?:python)?\s*(.*?) matches re.findall(pattern, text, re.DOTALL) if matches: return matches[0].strip() return text.strip() def run_pipeline(user_need: str, max_review_rounds: int 3): from agent import Agent prompts get_agent_prompts() requirement_agent Agent(prompts[0][0], prompts[0][1], workspace/requirement.md) plan_agent Agent(prompts[1][0], prompts[1][1], workspace/plan.md) coder_agent Agent(prompts[2][0], prompts[2][1], workspace/code.py) reviewer_agent Agent(prompts[3][0], prompts[3][1], workspace/review.md) print( 需求Agent开始拆解需求) requirement_text requirement_agent.run(user_need) print( 需求文档已生成workspace/requirement.md) print( 分析Agent开始输出实现方案) plan_text plan_agent.run(requirement_text) print( 实现方案已生成workspace/plan.md) code_text review_text for round_idx in range(1, max_review_rounds 1): print(f 编码Agent开始生成代码第 {round_idx} 轮) coder_input f需求文档\n{requirement_text}\n\n实现方案\n{plan_text} if review_text: coder_input f\n\n上一轮评审意见\n{review_text} code_text coder_agent.run(coder_input) code_text extract_code_from_markdown(code_text) print(f 代码已生成workspace/code.py第 {round_idx} 轮) print(f 评审Agent开始评审代码第 {round_idx} 轮) review_input ( f需求文档\n{requirement_text}\n\n f实现方案\n{plan_text}\n\n f待评审代码\n{code_text} ) review_text reviewer_agent.run(review_input) print(f 评审意见已生成workspace/review.md第 {round_idx} 轮) if REVIEW_RESULT: PASS in review_text.upper(): print( 评审通过协作流程结束) break if round_idx max_review_rounds: print( 达到最大评审轮数停止自动修复需要人工介入) return code_text, review_text if __name__ __main__: user_need ( 实现一个带缓存的斐波那契函数 fib(n)返回第 n 个斐波那契数。 注意处理 n 的边界值和参数异常。 ) code, review run_pipeline(user_need) print(\n 最终代码 ) print(code) print(\n 最终评审 ) print(review)这段代码是整套协作流程的调度中心。需要注意编码 Agent 在第二轮之后会把评审意见一起带上这样修复才有针对性。主循环设置了max_review_rounds默认最多 3 轮防止 Agent 在失败循环里消耗过多资源。5.3 为什么这样设计调度逻辑有读者可能会问为什么不把四个 Agent 的调用全部顺序写完然后结束问题在于没有处理“评审失败”的情况。真实开发中一次生成就有完美的代码是小概率事件更常见的是“生成-检查-修改-再检查”。这个循环结构是多 Agent 协作与简单管道调用的本质区别。另外中间产物全部落盘到workspace目录这个设计不是多余的。生产环境里你需要知道每个 Agent 基于什么生成、为什么做了某个修改。把中间产物落盘就相当于给整个流程加了审计日志。后续排查问题时直接看文件比重新跑一遍流程快得多。5.4 如果本地没有模型网关怎么验证流程如果你当前没有可用的模型服务也不想消耗真实 Token可以用一个简单的调试技巧在agent.py的run()方法中暂时用模拟返回替代真实调用。比如让需求 Agent 返回一段写死的 Markdown让编码 Agent 返回print(hello)。这样做的目的不是绕过真实模型而是先验证主流程中的文件读写、循环控制和字符串解析逻辑是否正确等模型服务就绪后再切回真实调用。这个调试思路在实际项目中非常实用。多 Agent 系统的复杂性主要来自流程编排而不是单个模型调用。先把流程跑通再接入真实能力排查问题的范围会小很多。6. 运行结果与效果验证6.1 运行命令确保.env文件配置正确后在项目根目录执行python main.py程序会依次打印四个 Agent 的执行日志最终在控制台输出最终代码和最终评审意见。所有中间文件会保存在workspace目录下。6.2 预期输出与判断标准由于模型的生成内容不固定这里给出一份“格式示意”让你知道正常流程长什么样不代表模型一定会输出同样的文字 需求Agent开始拆解需求 需求文档已生成workspace/requirement.md 分析Agent开始输出实现方案 实现方案已生成workspace/plan.md 编码Agent开始生成代码第 1 轮 代码已生成workspace/code.py第 1 轮 评审Agent开始评审代码第 1 轮 评审意见已生成workspace/review.md第 1 轮 评审通过协作流程结束判断流程是否成功主要看三个标志第一workspace目录下是否生成了四个文件requirement.md、plan.md、code.py、review.md。第二评审意见中是否包含REVIEW_RESULT: PASS。第三最终打印出的代码文件能否在本地直接运行并满足需求文档里的验收标准。6.3 代码验证技巧拿到workspace/code.py后建议单独执行一次验证其可运行性python workspace/code.py如果code.py包含的是函数定义可以临时在文件末尾追加几行调用验证。真实项目中你还可以把这段验证脚本写进自动化流程在评审 Agent 之后加一道程序化的冒烟测试进一步保证代码质量。注意这类自动生成的代码只能在隔离的测试环境中执行不要未经审计直接运行在生产环境或具有真实权限的系统中。6.4 运行失败时先看哪里很多第一次运行的人会直接盯着报错信息看。更高效的排查顺序是先检查环境变量是否被正确加载再确认模型网关是否可连通最后看是哪个 Agent 的调用失败了。前两步可以很快查出绝大多数问题。如果调用都成功但结果不符合预期问题通常出在 system prompt 上需要调节角色描述或输出格式要求。7. 常见问题与排查思路多 Agent 协作看起来代码量不大真正用起来会遇到各种意外。下面把最典型的几个问题和排查思路整理成表。问题现象可能原因排查方式解决方案启动后直接报错 API 连接失败LLM_BASE_URL配置错误或模型网关不可达检查.env配置使用 curl 或 Python 脚本访问网关健康检查接口修正网关地址确认网关服务已启动且网络策略允许访问模型返回内容无法写入文件workspace目录权限不足查看报错堆栈是否涉及PermissionError调整目录权限或让程序自动创建目录评审 Agent 输出里没有 PASS/FAILPrompt 输出格式约束失效查看workspace/review.md的原始内容在评审 Prompt 中强化“最后一行必须输出 REVIEW_RESULT”的指令或在后处理中用正则做容错解析编码 Agent 输出带 Markdown 代码块导致下游解析失败模型习惯性包装输出查看workspace/code.py是否包含 符号调用extract_code_from_markdown做后处理或在 Prompt 中再次强调只输出代码评审一直 FAIL陷入死循环评审标准过严或需求本身存在矛盾查看每轮评审意见是否指向同一类问题限制最大轮数简化评审维度必要时人工介入多轮循环后 Token 消耗过大每次把完整需求文档和方案重复传给编码 Agent查看每轮调用长度按阶段裁剪上下文只传增量信息或改用摘要机制同一个任务多次运行结果差异较大LLM 采样参数 temperature 过高对比不同 temperature 下的输出将 temperature 降到 0.2 或 0让生成更稳定代码生成了但函数逻辑是错的方案本身设计错误检查workspace/plan.md的算法描述优化分析 Agent 的 Prompt让它先写伪代码再写方案这里最容易被忽视的是第二种和第六种。目录权限问题看起来低级但在服务器部署时非常常见Token 消耗问题则是上生产环境后才暴露的隐性成本。建议在流程设计阶段就考虑哪些内容可以裁剪哪些历史信息不能丢尽量用“当前阶段需要的输入”而不是“历史所有输入”来调用模型。8. 多 Agent 协作的最佳实践与工程建议8.1 Prompt 设计输出格式比角色描述更关键在多 Agent 协作中Prompt 设计的第一优先级不是“让模型更像某个角色”而是“让模型的输出格式稳定”。为什么这么说因为单 Agent 使用时输出格式不稳定只影响你阅读多 Agent 协作时输出格式不稳定会导致下游解析失败、流程中断。建议在每个 Agent 的 Prompt 中明确写出输出结构并且提供一个小例子。例如评审 Agent 的 Prompt 可以附上一段格式示例比只写“请输出 PASS 或 FAIL”有效得多。另一个技巧是把“约束条件”放在 Prompt 的末尾。模型对 Prompt 开头和结尾的内容通常更敏感把最关键的格式约束放最后能显著提高遵守概率。8.2 上下文管理给每个 Agent 配一个“记忆窗口”多 Agent 协作中最常见的内存泄漏不是程序内存而是 Token 窗口。每次循环都把需求文档、方案、代码、评审意见全部拼进新 Prompt很快会超出模型上下文限制而且成本飞速上升。工程上的做法是为每个 Agent 定义明确的输入范围。需求 Agent 只看原始需求分析 Agent 只看需求文档编码 Agent 看需求文档加方案评审 Agent 看完所有内容但把它放在最后。修复循环中编码 Agent 不需要重读全部历史评审意见只需要最近一轮的评审意见。这种“按阶段裁剪”的思路在长流程中收益非常明显。8.3 循环控制与熔断机制自动修复是双刃剑。它能让系统在无人干预的情况下提升一次生成的质量但也可能因为评审标准不稳定而陷入无线循环。建议给所有可能反复执行的任务加上最大轮数限制。本文示例默认是 3 轮真实项目可以根据成本和延迟调整。更稳妥的做法是在循环中加入“问题聚类”逻辑。如果连续两轮评审指出的问题完全相同说明修复没有生效系统应该停止自动修复并通知人工。这是最简单的熔断机制避免浪费资源做无效迭代。8.4 安全边界密钥管理、代码执行与数据脱敏多 Agent 协作系统往往会被赋予更高的自动化权限所以安全边界必须清晰。第一密钥管理。调用大模型服务的密钥必须通过环境变量或配置中心注入不能硬编码更不能提交到 Git。密钥按最小权限原则分配不同的服务使用不同的密钥方便单独回收。第二代码执行。如果 Agent 生成的代码会被自动执行必须在沙箱容器或者隔离的测试环境中进行不能直接运行在与生产数据库、真实用户数据连通的环境里。执行前还要加一道审计步骤确保代码内容符合安全要求。第三数据脱敏。传入模型的内容可能包含业务敏感数据在调用外部模型服务之前要先做脱敏。不要在 Prompt 中传入真实账号、手机号、身份证号等个人数据。如果企业合规要求高建议采用私有化部署的模型服务从源头上控制数据出域风险。8.5 可观测性为每次运行生成 Trace ID生产环境中的多 Agent 协作必须可观测。最简单的方案是在每次执行主流程时生成一个 UUID 作为 Trace ID并把它写入所有中间文件的文件名或文件头。这样当用户反馈某个任务结果不对时运维人员可以直接通过 Trace ID 找到当时的所有中间产物和模型调用记录。如果没有这一步一旦出错所有过程信息都变成不可追溯的黑盒。在最小示例里workspace目录直接覆盖写入。真实项目建议按workspace/{trace_id}/组织目录一次运行一个目录避免并发任务互相覆盖。这个改造很小但对生产环境的排障价值非常大。8.6 从最小示例到生产框架如果你要把这套模式用到真实业务中不要直接拿main.py上生产。建议先做三件事第一将任务流转从同步函数调用改成消息队列或任务表让每个 Agent 可以独立部署和扩容第二把“需求、方案、代码、评审意见”建模成统一的任务状态引入状态机管理第三增加人工审批节点在关键动作如写文件、执行命令、发布变更前暂停流程。这个演进路径的核心不是技术堆叠而是职责边界。四个 Agent 在最小示例里共享同一个进程和同一份代码生产环境中它们可以是四个独立服务甚至可以使用不同的模型。重要的是职责边界不模糊需求和实现的边界、生成和评审的边界这些不能丢。9. 总结与后续学习方向这篇文章从“四个 Agent 分工协作”这个切入点出发完整拆解了一套最小可运行的多 Agent 协作实现。真正有价值的不只是那段 Python 代码而是背后的工程认知把一个大而全的 LLM 调用拆成多个小而专的 Agent通过明确的输入输出和循环控制提升复杂任务的整体稳定性。如果你现在准备动手实践我建议按这个顺序推进先跑通本文的最小示例重点观察workspace目录下各阶段产物是否合理然后替换成你自己的业务需求看四个角色的 Prompt 需要做哪些调整最后再考虑加入人工审批、Trace ID、沙箱执行这些生产级能力。不要一上来就引入重框架先把最小可行链路跑起来比什么都重要。值得继续深入的方向有三个第一是 LangGraph 这类专业编排框架它们提供了图状态、条件边、持久化等能力适合流程更复杂的场景第二是 Agent 的记忆管理如何在多次会话中保留关键信息、遗忘无关信息是让 Agent 真正能持续工作的核心第三是评测体系多 Agent 系统改动频繁你需要一套能定量评估“评审是否更严格、修复是否更有效”的自动化手段。最后提醒一句多 Agent 协作不是银弹它解决的是流程质量和可观测性问题不是模型推理能力问题。如果某个子任务单 Agent 都做不好拆成四个 Agent 只会放大错误。选好场景、控制好成本、守住安全边界这套协作模式才能真正成为你工具箱里的得力武器。希望这篇“我们四个真是太厉害了”的拆解能帮你少踩一些坑。