基于 AutoGen 构建的自动化软件工程工作流实测分析

这次实测的核心逻辑是构建一个包含 Product Manager、Engineer 和 Reviewer 三个 Agent 的闭环。在这种架构下，需求不再是直接喂给模型出代码，而是由 PM Agent 将模糊需求拆解为技术规格书，Engineer 编写代码，Reviewer 负责运行测试并反馈 Bug。最关键的转折点在于 UserProxyAgent 的配置，通过赋予其执行本地 Shell 命令的权限，代码在生成后能立即进入「编写-报错-自修复」的循环，而不需要人类在 IDE 和聊天窗口之间反复复制粘贴。

这意味着软件工程的重心正在从「如何写代码」转移到「如何定义 Agent 之间的协作协议」。在实测中，如果 Agent 之间的对话逻辑没有设定好（比如 Reviewer 过于宽松），系统很容易陷入死循环或者在错误的方向上过度优化。但一旦定义好严格的验收标准，这种自动化流能极大地降低重复性基建工作的心智负担。

对开发者而言，这带来了两个层面的冲击：

一是开发范式的改变。未来的编码可能更多是在编写 Agent System Prompt。比如，为了让 Engineer 减少幻觉，我给它注入了特定的上下文约束：

# 定义一个具有严格代码规范的 Engineer Agent
engineer = AssistantAgent(
    name="Engineer",
    llm_config=llm_config,
    system_message="你是一个精通 Python 的高级工程师。所有代码必须包含类型注解，且必须在输出代码前先写出逻辑伪代码。如果代码运行报错，请分析 Traceback 并直接给出修复方案。"
)

二是对「全栈」定义的重新定义。以前全栈是指精通前后端，现在全栈可能意味着你能搭建一套自动化的 Agent 工作流来覆盖从需求到部署的全生命周期。

但目前 AutoGen 的痛点依然明显，尤其是 Token 消耗量在多轮对话中呈指数级增长，且在处理复杂逻辑依赖时，Agent 之间容易出现「共识崩塌」——即两个 Agent 互相认同错误的结论。

目前的结论是：对于独立的小工具开发或模块化程度高的功能实现，这套工作流能提升 60% 以上的效率；但对于需要深度架构思考的大型项目，它依然是一个极其强大的「辅助驾驶」，而非完全的「自动驾驶」。