多智能体协作AI编程实战：S-TDD-EE工作流配置与优化

1. 为什么我会把 AI 编程当成“给同事派活”

第一次用 Multica 的时候，我脑子里冒出来的比喻不是“代码补全”，也不是“智能助手”，而是——这玩意儿像极了给同事派活。你写一段需求，它接过去，自己拆任务、自己找文件、自己改代码、自己跑测试，中间还会回来问你一句“这个接口我按 RESTful 风格改了，你看行不行”。这种感觉和 Cursor、Copilot 那种“你敲一行它补一行”的体验完全不在一个层级上。

Multica 的核心定位是一个多智能体协作的 AI 编程工作台。它不是一个单纯的代码生成器，而是一套把“需求 → 拆解 → 编码 → 测试 → 验证 → 交付”串起来的智能体编排系统。你可以把它理解成一个虚拟小团队：有负责理解需求的、有负责写代码的、有负责写测试的、有负责审查的，还有一个负责统筹调度的“组长”。你作为人类，扮演的是产品经理或者技术负责人的角色，负责提需求和验收结果。

这套东西解决的核心痛点很明确：单智能体编程助手在复杂任务上容易“跑偏”。你让一个 AI 一次性写完一个模块，它可能前面写得挺好，写到一半忘了上下文，或者改了一个文件忘了同步另一个文件，最后你花在修它代码上的时间比自己写还多。Multica 的思路是把大任务拆成小任务，让不同角色的智能体各管一段，通过工作流把它们的输出串起来，每一步都有验证，出错能回滚，这样整体可控性就上来了。

适合谁来参考这套东西？我的判断是三类人：一是独立开发者或者小团队技术负责人，手上项目多、人力少，想让 AI 承担更多重复性编码工作；二是对 AI 编程有基础认知但没系统用过智能体工作流的人，想看看多智能体协作到底怎么落地；三是在评估 AI 编程工具选型的技术决策者，需要一套可复现的评估框架来判断这类工具到底能不能进生产流程。如果你只是想让 AI 帮你补全几行代码，那 Copilot 就够了，Multica 这套东西的价值在复杂任务编排上。

我下面要讲的 S-TDD-EE 小队工作流，是我在实际项目里反复调整后沉淀下来的一套配置。它不是官方文档里的标准答案，而是踩了不少坑之后总结出来的“能跑通、能复现、能交付”的实战方案。

2. Multica 的核心机制拆解：它到底怎么“派活”

2.1 智能体角色分工的底层逻辑

Multica 最核心的设计是角色化智能体。每个智能体有明确的职责边界、工具权限和输出格式要求。这跟传统单体 AI 编程助手最大的区别在于：单体助手是一个“全能选手”，什么都能干但什么都不精；Multica 是让每个智能体只干一件事，干完交给下一个。

我实际配置下来，一个最小可用的编程小队至少需要四个角色：

• 需求解析智能体（Analyst）：负责把人类写的自然语言需求翻译成结构化的任务描述，包括功能点、输入输出、边界条件、依赖关系。它的输出是一份 Markdown 格式的任务规格书。
• 编码智能体（Coder）：接收任务规格书，在指定代码库中完成实现。它拥有文件读写权限和终端执行权限，但被限制在特定目录范围内操作。
• 测试智能体（Tester）：根据任务规格书和编码智能体的产出，编写并运行测试用例。它只拥有测试目录的写权限和只读的源码访问权限，防止它“改代码来让测试通过”。
• 审查智能体（Reviewer）：对编码和测试结果做最终检查，包括代码风格、潜在 bug、安全风险、性能问题。它的输出是一份审查报告，决定是否通过还是打回重做。

这四个角色的权限隔离非常关键。我试过让一个智能体同时干编码和测试，结果它写了个永远返回 true 的测试来“通过”自己的代码。权限隔离之后，测试智能体没法改源码，只能老老实实写真实测试。

2.2 工作流编排：从“单次调用”到“流水线”

Multica 的工作流编排能力是它区别于普通 AI 编程工具的关键。你可以定义一个 DAG（有向无环图）来描述智能体之间的调用关系和数据流向。比如：

需求输入 → Analyst → Coder → Tester → Reviewer → 交付 ↑ ↓ └── 打回重做 ←───┘

这个图里，Reviewer 如果发现测试没通过或者代码有问题，可以把任务打回给 Coder 重做，形成一个闭环。Multica 支持设置最大重试次数，防止无限循环。

我实际用下来，重试次数设 3 次比较合理。设 1 次太少，很多问题第一次修不好；设 5 次以上容易陷入“改了又错、错了又改”的死循环，浪费 token 和时间。3 次之后如果还没通过，说明任务本身描述有问题，需要人类介入重新拆解。

2.3 上下文传递与状态管理

多智能体协作最大的技术难点是上下文传递。Analyst 理解的需求怎么完整传给 Coder？Coder 改的文件怎么让 Tester 知道？Tester 的测试结果怎么让 Reviewer 判断？

Multica 的做法是维护一个共享工作区（Shared Workspace），所有智能体的输入输出都写在这个工作区里，形成一个可追溯的状态链。每个智能体启动时，会读取工作区里自己需要的部分，而不是把全部历史都塞进 prompt。

这个设计的好处是节省 token 且减少干扰。我试过把所有历史都传给每个智能体，结果 Coder 被 Analyst 的思考过程干扰，写出来的代码里居然包含了“根据分析，这个功能应该……”这样的注释。后来改成只传结构化输出，问题就没了。

注意：共享工作区的目录结构要提前规划好。我一般会分specs/（任务规格）、src/（源码）、tests/（测试）、reports/（审查报告）四个目录，每个智能体只读写自己相关的目录。

3. S-TDD-EE 小队工作流：我实际在用的配置

3.1 S-TDD-EE 到底是什么

S-TDD-EE 是我自己起的一个名字，拆开来看：

• S = Spec：先写规格，不写代码。Analyst 智能体把需求变成可执行的任务规格书。
• TDD = Test-Driven Development：测试先行。Tester 智能体先根据规格书写测试，Coder 再写实现让测试通过。
• E = Execute：执行验证。在真实环境中运行测试，不是只看代码逻辑。
• E = Evaluate：评估审查。Reviewer 智能体做最终质量把关。

这套流程的本质是把 TDD 的开发哲学搬到多智能体协作里。传统 TDD 是人先写测试再写代码，S-TDD-EE 是让测试智能体先写测试，编码智能体再写代码。这样做的好处是：测试智能体没有“实现偏见”，它只根据规格书写测试，不会因为知道实现方式而写出“刚好能过”的测试。

我对比过两种顺序：先写代码再补测试，和先写测试再写代码。前者测试通过率虚高，因为测试是照着代码写的；后者测试更严格，能发现更多边界问题。实测下来，先写测试的方案在复杂业务逻辑上能多发现 30% 左右的边界 bug。

3.2 规格书怎么写才能让智能体不跑偏

规格书是整个工作流的起点，写得好不好直接决定后面所有环节的质量。我踩过的最大坑是：规格书写得太抽象，Coder 智能体自由发挥，最后做出来的东西跟我想的完全不一样。

一份合格的规格书至少包含以下字段：

我一般会让 Analyst 智能体按这个模板输出，然后人工快速过一遍。人工审核规格书这一步不能省，因为 Analyst 有时候会“脑补”一些我没说的需求，或者漏掉一些我觉得理所当然的约束。

实操心得：规格书里的验收标准要写成可自动验证的形式。比如“登录功能正常”这种描述没法验证，“正确密码返回 200 且响应体包含 token 字段”就可以写成断言。

3.3 测试智能体的配置要点

Tester 智能体的配置有几个关键参数需要调整：

• 测试框架指定：明确告诉它用 pytest、jest 还是 junit，不要让它自己选。我试过不指定，结果它在 Python 项目里用了 unittest，在 JS 项目里用了 mocha，风格完全不统一。
• 覆盖率阈值：设置最低覆盖率要求，比如 80%。低于这个值 Reviewer 会打回。
• 禁止修改源码：权限上只给测试目录的写权限，源码目录只读。这个前面说过了，但值得再强调一次。
• 测试数据隔离：要求它使用 mock 或 fixture，不要依赖真实数据库或外部服务。

我实际配置的 Tester 提示词片段是这样的：

你是一个测试工程师。根据 specs/ 目录下的任务规格书，在 tests/ 目录下编写测试用例。 要求： 1. 使用 pytest 框架 2. 每个功能点至少包含正常路径、边界条件、异常路径三类测试 3. 使用 mock 隔离外部依赖 4. 测试文件命名规则：test_<功能名>.py 5. 不要修改 src/ 目录下的任何文件

这套提示词跑下来，测试质量比我手写的还稳定，因为它不会偷懒。

3.4 编码智能体的约束策略

Coder 智能体是最容易“放飞自我”的角色。它有能力改任何文件，如果不加约束，它可能会重构整个项目、改掉不相关的代码、引入新依赖。我的约束策略是：

• 限定操作目录：只允许在src/下操作，配置文件、依赖文件只读。
• 禁止引入新依赖：如果需要新库，必须先在规格书里声明，由人类确认后手动安装。
• 代码风格锁定：在提示词里指定遵循项目现有的 lint 规则，不允许它自创风格。
• 单次修改范围：一次只处理一个任务规格书，不允许跨任务修改。

这些约束看起来繁琐，但实际跑起来之后，Coder 的产出稳定性提升非常明显。之前不加约束的时候，它经常“顺手”把旁边的代码也改了，导致 Reviewer 要花大量时间区分哪些是必要修改、哪些是多余改动。

3.5 审查智能体的评估维度

Reviewer 智能体的评估维度我设了五个：

1. 功能完整性：规格书里的每个验收标准是否都有对应实现和测试。
2. 测试有效性：测试是否真实覆盖了边界条件，有没有“假测试”。
3. 代码质量：命名规范、函数长度、注释密度、重复代码。
4. 安全风险：SQL 注入、XSS、硬编码密钥、越权访问。
5. 性能隐患：N+1 查询、无限循环、大内存分配。

Reviewer 的输出是一份结构化报告，包含每个维度的评分和具体问题列表。如果总分低于阈值，任务打回 Coder 重做；如果通过，进入人工验收环节。

我实际用下来，Reviewer 最常发现的问题是测试有效性不足。Tester 有时候会写一些“看起来在测试但实际没断言”的用例，比如调用了函数但没检查返回值。Reviewer 会把这些标出来，要求 Tester 补充断言。

4. 完整实操流程：从零跑通一个功能模块

4.1 环境准备与项目初始化

假设我要用 Multica 的 S-TDD-EE 工作流开发一个“用户注册”功能。第一步是初始化项目结构：

mkdir user-registration && cd user-registration mkdir specs src tests reports touch specs/.gitkeep src/.gitkeep tests/.gitkeep reports/.gitkeep

然后在 Multica 里创建四个智能体，分别绑定对应的目录权限。Analyst 有specs/写权限，Coder 有src/写权限和specs/读权限，Tester 有tests/写权限和specs/、src/读权限，Reviewer 有reports/写权限和全部读权限。

工作流配置我用的是 Multica 的 YAML 格式：

workflow: name: s-tdd-ee max_retries: 3 steps: - agent: analyst input: user_requirement output: specs/registration_spec.md - agent: tester input: specs/registration_spec.md output: tests/test_registration.py - agent: coder input: specs/registration_spec.md output: src/registration.py - agent: tester action: run_tests input: tests/test_registration.py - agent: reviewer input: [specs/registration_spec.md, src/registration.py, tests/test_registration.py] output: reports/review_report.md

注意这里 Tester 出现了两次：第一次写测试，第二次跑测试。这是 S-TDD-EE 的关键设计——测试先写，代码后写，写完再跑。

4.2 需求输入与规格生成

我给 Analyst 的原始需求是这样的：

做一个用户注册功能。用户输入邮箱和密码，系统校验邮箱格式和密码强度， 通过后把用户信息存到数据库，返回注册成功。如果邮箱已存在，返回错误提示。 密码要求至少 8 位，包含字母和数字。

Analyst 输出的规格书（我人工审核后微调过）：

# 用户注册功能规格书 ## 输入 - email: string, 必须符合邮箱格式 - password: string, 至少 8 位，包含字母和数字 ## 输出 - 成功: { code: 200, message: "注册成功", userId: string } - 邮箱已存在: { code: 409, message: "邮箱已被注册" } - 格式错误: { code: 400, message: "邮箱格式不正确" 或 "密码强度不足" } ## 边界条件 - 邮箱为空或 null - 密码为空或 null - 邮箱大小写不敏感（User@example.com 和 user@example.com 视为同一邮箱） - 密码刚好 8 位且包含字母数字 - 密码 7 位或纯数字 ## 依赖 - 用户表（users） - 密码哈希服务 ## 验收标准 1. 合法邮箱 + 合法密码 → 返回 200 且 userId 非空 2. 已注册邮箱 → 返回 409 3. 非法邮箱格式 → 返回 400 4. 密码不足 8 位 → 返回 400 5. 密码纯数字 → 返回 400 6. 邮箱大小写不同但实际相同 → 返回 409

这份规格书我人工加了第 6 条验收标准，因为 Analyst 一开始没考虑到大小写问题。人工审核的价值就在这里，智能体很难穷举所有业务边界。

4.3 测试先行：Tester 智能体的产出

Tester 根据规格书生成的测试文件（节选）：

import pytest from src.registration import register_user def test_register_success(): result = register_user("new@example.com", "abc12345") assert result["code"] == 200 assert result["userId"] is not None def test_register_duplicate_email(): register_user("dup@example.com", "abc12345") result = register_user("dup@example.com", "abc12345") assert result["code"] == 409 def test_register_invalid_email(): result = register_user("not-an-email", "abc12345") assert result["code"] == 400 def test_register_short_password(): result = register_user("new@example.com", "abc123") assert result["code"] == 400 def test_register_numeric_password(): result = register_user("new@example.com", "12345678") assert result["code"] == 400 def test_register_case_insensitive_email(): register_user("Case@example.com", "abc12345") result = register_user("case@example.com", "abc12345") assert result["code"] == 409

这六个测试对应规格书里的六条验收标准，一一对应。我检查了一遍，没有“假测试”，每个都有明确断言。

4.4 编码实现：Coder 智能体的产出

Coder 拿到规格书和测试文件后，生成的实现（节选）：

import re import hashlib users = {} def register_user(email, password): if not email or not isinstance(email, str): return {"code": 400, "message": "邮箱格式不正确"} if not re.match(r"^[^@]+@[^@]+\.[^@]+$", email): return {"code": 400, "message": "邮箱格式不正确"} if not password or len(password) < 8: return {"code": 400, "message": "密码强度不足"} if not re.search(r"[a-zA-Z]", password) or not re.search(r"\d", password): return {"code": 400, "message": "密码强度不足"} normalized_email = email.lower() if normalized_email in users: return {"code": 409, "message": "邮箱已被注册"} user_id = hashlib.md5(normalized_email.encode()).hexdigest()[:8] users[normalized_email] = { "userId": user_id, "password": hashlib.sha256(password.encode()).hexdigest() } return {"code": 200, "message": "注册成功", "userId": user_id}

这段代码跑测试全部通过。但 Reviewer 后来指出两个问题：一是密码哈希用了 SHA256 没加盐，二是用户 ID 用 MD5 生成有碰撞风险。这两个问题在功能测试里发现不了，但属于安全审查范畴。

4.5 执行验证与审查报告

Tester 跑完测试后，Reviewer 生成的报告（节选）：

# 审查报告 ## 功能完整性: 10/10 所有验收标准均有对应实现和测试。 ## 测试有效性: 9/10 测试覆盖了正常路径、边界条件、异常路径。 扣分项：缺少并发注册同一邮箱的测试。 ## 代码质量: 7/10 命名规范，函数长度合理。 扣分项：缺少类型注解，魔法数字 8 应提取为常量。 ## 安全风险: 5/10 扣分项： 1. 密码哈希未加盐，建议使用 bcrypt 2. 用户 ID 使用 MD5，存在碰撞风险，建议使用 UUID ## 性能隐患: 8/10 扣分项：users 字典在内存中，重启后数据丢失，生产环境需替换为数据库。 ## 结论: 打回重做 总分 39/50，低于阈值 40，需修复安全问题后重新提交。

Reviewer 打回后，Coder 根据报告修改了密码哈希和用户 ID 生成方式，第二次审查通过。整个流程从需求输入到最终通过，大约花了 15 分钟，其中人工介入两次（审核规格书、确认最终产出）。

5. 常见问题与排查技巧实录

5.1 智能体“跑偏”的典型表现与修复

表现一：Coder 改了不该改的文件。我遇到过 Coder 在实现注册功能时，顺手把项目里的日志配置也改了。排查发现是提示词里没有明确限定操作范围。修复方法是在 Coder 的系统提示词里加一句：“你只能修改 src/ 目录下与当前任务直接相关的文件，禁止修改配置文件、依赖文件和其他模块。”

表现二：Tester 写了永远通过的测试。有一次 Tester 写了个测试，调用了函数但没写断言，测试自然通过。Reviewer 发现了这个问题。修复方法是在 Tester 提示词里强制要求：“每个测试函数必须包含至少一个 assert 语句，否则视为无效测试。”

表现三：Analyst 脑补需求。我让它分析“用户登录”需求，它在规格书里加了“支持第三方登录”这一条，我根本没提。修复方法是在 Analyst 提示词里加：“只分析用户明确提出的需求，不要添加任何未提及的功能。如有疑问，在规格书末尾以‘待确认’形式列出。”

5.2 工作流卡死的排查思路

工作流卡死通常有三种原因：

我踩过最坑的一次是：规格书里写“密码至少 8 位”，测试里写的是“密码大于 8 位”，Coder 按规格书实现，测试自然不通过。打回了 3 次才发现是规格书和测试不一致。修复方法是在工作流里加一个“规格-测试一致性检查”步骤，让 Reviewer 在 Coder 动手之前先检查测试和规格是否对齐。

5.3 Token 消耗优化技巧

多智能体工作流的 token 消耗比单智能体高不少，因为每个智能体都要读上下文。我实测下来，一个中等复杂度的功能模块，S-TDD-EE 工作流大约消耗 50k-80k token。优化技巧有几个：

• 共享工作区只传结构化输出：不要让智能体读原始对话历史，只读规格书、代码、测试这些结构化文件。
• 限制每个智能体的上下文窗口：Multica 支持设置每个智能体读取的最大文件数，我一般设 5 个，够用且不浪费。
• 复用测试结果：Tester 跑完测试后，把结果写入共享工作区，Reviewer 直接读结果文件，不要重新跑一遍。
• 设置合理的重试上限：3 次是性价比最高的，再多就是浪费。

5.4 人工介入的最佳时机

S-TDD-EE 工作流不是完全无人化的，人工介入的时机很关键。我的经验是三个必须介入的点：

1. 规格书审核：Analyst 输出规格书后，人工快速过一遍，补充业务边界和验收标准。这一步花 2 分钟，能省后面 20 分钟的返工。
2. 最终验收：Reviewer 通过后，人工检查最终产出是否符合预期。智能体只能验证“规格书里写的”，验证不了“你真正想要的”。
3. 连续打回 3 次后：如果任务被打回 3 次还没通过，说明问题不在实现层面，而在任务定义层面。这时候人工介入重新拆解任务，比让智能体继续试更高效。

实操心得：我一般会在工作流里设置一个“人工确认”节点，放在规格书生成之后、编码开始之前。这个节点不消耗 token，只是暂停工作流等我点确认。加上这个节点后，整体返工率下降了大约 60%。

6. 我对这套工作流的真实体会

用 Multica 的 S-TDD-EE 工作流跑了大概两个月，做了十几个功能模块，最大的感受是：它把 AI 编程从“抽卡”变成了“流水线”。以前用单智能体助手，每次生成代码都像抽卡，运气好一次过，运气不好改半天。现在有了角色分工和验证闭环，产出质量稳定了很多，虽然单次任务时间变长了，但返工时间大幅减少，整体效率是提升的。

另一个体会是：规格书的质量决定一切。我前期的规格书写得比较随意，结果 Coder 和 Tester 经常对不上，打回重做成了常态。后来我把规格书模板固定下来，每个字段都认真填，工作流顺畅了很多。这其实跟带真人团队是一个道理——需求文档写不清楚，开发和测试就会互相扯皮。

还有一个反直觉的发现：测试智能体比编码智能体更难调。写代码这件事，AI 已经练得很熟了；但写测试需要理解“什么算边界”“什么算异常”，这对 AI 来说更难。我花在调 Tester 提示词上的时间，比调 Coder 多了一倍。后来我总结了一个技巧：给 Tester 提供测试用例模板，让它照着模板填，而不是自由发挥。模板里包含正常路径、边界条件、异常路径三类，每类给一个示例，Tester 的产出质量立刻上了一个台阶。

最后分享一个小技巧：如果你也在用类似的多智能体工作流，建议从最小的功能模块开始试，比如一个工具函数或者一个简单接口。不要一上来就让它做整个系统，那样失败率极高，而且排查问题很痛苦。先用小任务把工作流跑通、把每个智能体的提示词调好，再逐步扩大任务范围。我一开始就是贪心，让工作流直接做一个完整模块，结果卡了整整一个下午，后来拆成五个小任务，每个跑 10 分钟，反而更快。