MetaGPT：多智能体软件公司，一句话让 AI 团队写代码

开篇：被“重复造脚本”逼疯的三个月

去年我负责数据交付团队，每个月要为客户编写上百个格式各异的数据清洗脚本。客户给的是Excel、CSV、JSON甚至PDF里的表格，需求却高度相似——“把这几列去掉”“日期格式统一”“缺失值填成0”。团队三人每天加班到深夜，写出的代码大量重复，但客户验收时仍常纠结于字段命名和注释风格。最崩溃的一次，一个客户把需求改了五遍，我们跟着改了五轮代码——改第一轮花了6小时，后面每轮也要2小时。我意识到，单纯靠人肉堆时间不是出路，我要让AI来做“需求理解→设计→编码”的流水线。

需求拆解

我花了两周去访谈客户和团队，把痛点拆成可执行的技术需求：

• 数据：需要积累一套高质量示例脚本库（至少500个），覆盖常见清洗模式，用于微调或作为上下文示例；同时要有明确的输入输出接口，便于自动验证。
• 性能：单个任务从自然语言需求到可运行代码的生成耗时不能超过15分钟（人工是3-4小时）。代码必须能在Python 3.9环境直接运行，且通过率（即一次跑通）不低于70%。
• 成本：每次完整生成调用的模型费用不能超过2元人民币（按GPT-4 token计费估算），否则摊到客户单子上不划算。
• 部署约束：公司内网要求所有代码生成和运行必须在私有服务器完成，不能把客户数据直接送到外部API，需要支持代理或本地模型。

方案设计：为什么是MetaGPT

备选方案有三个：单模型直接生成（用GPT-4提示词模板）、LangChain的Agent串行调用、以及MetaGPT的“模拟软件公司”架构。

单模型生成虽然便宜，但面对“需要先写设计文档再写代码”的长流程任务时，经常忘记需求细节，且中间没有验证节点，出错了只能整段重来。LangChain的Agent灵活，但角色分工要自己写很多代码，我们团队没人有空维护复杂的工具调用逻辑。

MetaGPT把“产品经理→架构师→项目经理→工程师→测试”这套角色固化进流程，输入一句话，它会产出：PRD文档、系统设计、任务列表、代码文件、测试用例。这正好匹配我们“文档→代码”的现实交付链条，而且它的人工反馈机制允许在关键节点插入检查，保证了质量。缺点是要装一套依赖较多的环境，且API key需要统一管理，但这些构不成拦截项。

最终选了MetaGPT v0.5.x版本，因为它的角色定义清晰、社区活跃，更重要的是它内置了Python和TypeScript的代码执行校验器，能自动跑pytest。为了避开数据出网，我部署在公司内网服务器上，并配置代理转发到API网关。

落地实现

第一步：搭建环境与数据准备

我在内网Linux服务器上（8核32G）创建了Python 3.10的venv，安装MetaGPT及其依赖。为了满足私有化要求，我把API密钥放在环境变量里，并让MetaGPT通过一个内部网关访问模型——这样客户数据不会直接暴露给第三方。

# 部署脚本（已脱敏）
mkdir /opt/metagpt && cd /opt/metagpt
python3.10 -m venv venv
source venv/bin/activate
pip install -U metagpt
# 配置模型代理（内网网关地址示例，不可公网访问）
export OPENAI_API_BASE="http://10.20.30.40:8080/v1"
export OPENAI_API_KEY="only-for-internal-usage"
# 初始化MetaGPT配置目录
metagpt init

数据准备的重头戏是整理示例脚本库。我按照MetaGPT的预期输入格式，为每类清洗任务写了一批“需求文本→期望代码”的配对样本，放到data/custom_examples/下。在配置里通过examples_repo字段指向该目录，这样MetaGPT在生成时能参考这些真实案例，而不只依赖模型的预训练知识。

第二步：编写流程配置与角色调优

MetaGPT的流程由配置文件驱动，我在config/metagpt_ext.yaml里做了三处关键调整：一是把角色内的max_retry设为2，防止小概率的解析失败；二是开启code_review功能，让测试角色真正执行生成的代码并反馈报错；三是关闭了不必要的角色（如写长文档的运营“观察员”），减少token浪费。

# config/metagpt_ext.yaml 关键段
project_name: "data_cleaner"
roles:
  pm:
    max_retry: 2          # 需求解析失败重试次数
  engineer:
    max_retry: 2
  tester:
    run_code: true        # 必须实际执行代码，不能只看静态检查
    pytest_exec: "pytest -q --timeout=30"
code_review: true
examples_repo: "/opt/metagpt/data/custom_examples"
llm:
  temperature: 0.1        # 代码生成需要低随机性，减少无谓变更

这部分调试花了3天，主要是在角色间的交接信息上做减法：MetaGPT默认传递大量文档内容会给较长的对话上下文，但代码任务只需“需求清单”和“设计要点”，所以我在配置里限制了max_meta_path_length和compress_threshold，把丢进去的历史token压缩到原来的40%。

第三步：部署成内网服务

为了让团队不用去敲命令行，我用FastAPI包了一层简单的HTTP服务，接受“任务描述+参数文件”，内部调用MetaGPT的流程，轮询任务状态并在结束时返回代码和测试报告。同时监听:8088端口供统一网关转发权限。

# serve.py (简化版)
from fastapi import FastAPI, BackgroundTasks
from metagpt.software_company import generate_repo
app = FastAPI()

@app.post("/generate")
async def generate_task(req: dict, bg: BackgroundTasks):
    task_id = str(uuid.uuid4())
    bg.add_task(run_metagpt, task_id, req["desc"], req["params"])
    return {"task_id": task_id}

def run_metagpt(task_id, desc, params):
    # 内部调用MetaGPT主流程，并记录结果到 /tmp/metagpt/{task_id}
    generate_repo(desc, run_code=1, git_repo=/tmp/metagpt/{task_id}, project_name="task")

因为客户文件涉及敏感数据，我额外加了一个--allow-customer-data的白名单检查，确保传输过程中不会意外写入临时文件，同时将生成代码的字节码大小限制在500KB以内，避免模型产生大段冗余注释。

效果与数据

上线试运行两周后，我记录了20个真实交付任务的对比数据。这些任务都是我们之前手工完成过的标准清洗脚本，复杂度属于中等（50-200行代码）。结果如下：

这里要诚实地说：78%的首测通过率中有10%是“测试已通过但不符合客户字段命名习惯”，需要人工微调；另外有5%的任务MetaGPT完全跑不动，因为需求文本包含太多口语化缩写，后来我加了“需求规范化”prompt才把这一类从9%降到5%。整体来说，效率提升是实打实的，我们团队因此减掉了一个“初稿写手”的岗位，转型做评审和微调。

踩过的坑

坑1：生成的代码引用了不存在的库

现象：MetaGPT产出的代码经常使用pandas.read_excel，但内网服务器Python环境没装pandas，首测直接ImportError。

排查：我打开测试日志发现是tester角色运行代码时环境变量不干净，且MetaGPT没有在生成流程中自动安装依赖。人工作业时会先pip install，但MetaGPT不考虑。

解决：在配置里让tester角色增加一个“环境依赖检测”步骤，读取代码里的import语句，然后走内网pip镜像安装。同时我把服务器上的Python镜像做了预置：pip install pandas openpyxl numpy flask pytest，这样90%的情况直接可用。

坑2：多轮重试导致Token爆炸

现象：某些复杂需求会触发MetaGPT的max_retry机制，每一次retry都会把历史消息重复编码，导致一次任务消耗掉50万token（费用超预算），而实际只重试了两次。

排查：打开MetaGPT日志发现，对话轮次之间会保留所有中间文档（PRD、设计、代码审查意见），当这些文档过于冗长时，token数呈指数增长。

解决：我改了配置：把历史文档的“全文传递”改为“摘要传递”，关键信息用结构化文本框传。另外设置了max_total_tokens：如果调用累计超过20万token，直接终止并提示人工介入。这项调整让平均token消耗从每单12万降到4万，成本稳定在2元以内。

坑3：参考示例被过度绑定

现象：我在示例库中放了一个“按客户ID分组求和”的典型案例，结果后续所有任务生成的代码都和这个案例高度相似，哪怕需求明明是“按日期去重”。

排查：检查发现，MetaGPT把examples_repo里的文件内容全部塞进prompt，且没有做相似度过滤。当示例数量多时，模型倾向于跟随第一个示例的风格。

解决：我改用了“按需求关键词选择示例”的方式，只挑3-5个最匹配的案例加入上下文。在MetaGPT里可以覆盖prepare_examples方法，或者更简单——在需求描述前手动添加“这是示例：”。我自己在调用generate_repo前写了一个Python脚本，根据关键词（“分组”“去重”“日期格式”）从示例库中检索出Top5文件路径，然后拼接到配置里。这样既保留了示例的指导作用，又不至于垄断输出格式。

复盘与扩展

复盘下来，我判断当初最正确的决策是：坚决不直接让模型输出完整代码，而是利用MetaGPT的“产品经理—架构师—工程师”链条，让需求被多次翻译后再写代码。这虽然增加了生成时间（相比单调用多花30%），但明显减少了“答非所问”的情况，尤其在遇到客户需求的模糊表述时，PRD环节会强制澄清。

做得不够好的地方是：我没有一开始就建立需求规范化的前置处理，导致口语化输入直接进了流程，拉低了通过率。如果重来，我会加一个LLM预处理器，先把“把日期改成20120304格式”统一成“date_format: %Y%m%d”。另外，MetaGPT的并行任务能力没有榨干，我们目前是串行跑任务，其实服务器还有余力，可以用它的Dispatcher组件实现多任务队列，还能再提速50%。

扩展方向有两个正在推进：一是把“自动生成代码→自动执行→自动写交付报告”全部串成一条服务，客户只要点“确认”就能拿结果；二是接上企业微信机器人，团队只要在群里发需求，MetaGPT完成后把代码和测试报告回传卡片，这会进一步消灭交互摩擦。如果你也面临类似的“重复编码”困境，不妨从一个小场景（比如数据清洗脚本）开始试点，MetaGPT的上手曲线会比你想的更平。