复杂代码逻辑的优化从来不只是把函数写短。真正的难点在于，一段条件判断可能同时牵动用户状态、订单金额、活动配置以及历史版本里遗留下来的兼容规则。单个代码智能体如果只基于当前文件做局部推理，很容易生成一个局部合理、全局不可用的补丁。MiMo Code Agent 的协同模式通过引入规划、实现、评审、测试多个角色，把一次性的代码改写转化为可收敛的迭代过程，让每一步修改都有明确的校验点和回退依据。

一、为什么单点生成在复杂逻辑上容易失效

复杂代码逻辑通常具备几个共同特征：条件分支互相嵌套、状态来源分散、隐性业务规则多、自动化测试覆盖不足。面对这样的代码，优化目标不只是降低圈复杂度，还要保持外部行为完全不变。单个智能体在长上下文中容易被局部信息吸引，例如看到一串 if-else 就直接改写成查表结构，却没有确认某个分支是否依赖外部服务的返回顺序，也没有检查是否存在调用方依赖原始函数抛出的异常类型。

另一个典型问题是过度自信补丁。模型倾向于输出看起来完整的方案，却很少主动列出可能受影响的调用方和边界条件。处于生成角色时，它更多关注如何完成当前任务，而不是主动寻找反例。协同模式将生成与审查拆开后，情况会明显改善：实现角色专注候选方案，评审角色从调用图、接口契约和测试报告中寻找证据，测试角色用等价性用例验证行为是否漂移。这样并不是简单增加模型调用次数，而是把原本一次生成中隐藏的风险，转化为多轮可追踪的显式检查。

因此，当函数分支超过一定数量、涉及多个数据来源，或者缺乏可靠测试基线时，就不应再把优化任务当作一个简单的文本改写。使用多角色协同，可以显著降低重构后行为漂移的概率，也让优化过程更容易被人工评审接受。

二、MiMo Code Agent 协同模式如何构建可收敛的优化闭环

MiMo Code Agent 协同模式的核心可以抽象为四个角色：规划、实现、评审、测试。规划角色接收优化意图，结合代码上下文圈定影响面，输出修改约束和候选方案边界。实现角色根据规划结果生成补丁。评审角色不直接修改代码，而是检查补丁是否满足约束、是否存在副作用、是否符合项目规范。测试角色运行已有用例和临时补充的等价性用例，把失败信息回传给实现角色。这个过程会持续迭代，直到没有新的评审问题且测试全部通过。

调度循环可以用下面的伪代码表示：

plan = planner.create_plan(task, codebase_context)
feedback = []
for iteration in range(max_iterations):
    patch = implementer.generate(plan, feedback)
    issues = reviewer.review(patch, constraints)
    test_result = runner.run(patch)
    if not issues and test_result.passed:
        break
    feedback = issues + test_result.failures

这里的关键在于反馈数据结构。评审问题和测试失败不能只返回一句自然语言，最好包含文件路径、行号、失败断言和期望行为。这样实现角色在下一轮生成时才能精准修正，而不是从头重写。协同模式也强调约束传递，比如规划角色可以明确要求保持函数签名不变、不改变异常类型、禁止引入新的第三方依赖。这些约束写在计划中，评审角色据此检查，测试角色据此设计用例，整个闭环才不会跑偏。

三、订单折扣重构的完整推演

假设有一个订单折扣计算函数，原始实现如下：

def calc_discount(user, order):
    if user.vip:
        if order.total > 1000:
            return 0.8
        elif order.total > 500:
            return 0.85
        else:
            return 0.9
    else:
        if order.total > 1000:
            return 0.95
        else:
            return 1.0

这段代码虽然短，但条件分支已经出现重复判断和硬编码阈值。如果后续增加地域活动、优惠券叠加或企业客户折扣，函数会继续膨胀。协同模式的处理步骤如下：规划角色先识别出两个判断维度，即用户是否 VIP 和订单金额区间，并明确优先级顺序为 VIP 优先、金额阈值次之。测试角色根据当前行为固化一组用例，覆盖普通用户低金额、普通用户高金额、VIP 低金额、VIP 中金额、VIP 高金额五种情况。实现角色随后生成规则表版本。

重构后的代码可以写成：

DISCOUNT_RULES = [
    (lambda c: c.user.vip and c.total > 1000, 0.8),
    (lambda c: c.user.vip and c.total > 500, 0.85),
    (lambda c: c.user.vip, 0.9),
    (lambda c: not c.user.vip and c.total > 1000, 0.95),
]
def calc_discount(ctx):
    for predicate, discount in DISCOUNT_RULES:
        if predicate(ctx):
            return discount
    return 1.0

这个版本去掉了嵌套判断，用规则列表表达匹配顺序。它更容易扩展，新增一条地域规则时只需要在列表相应位置插入，不需要改动主流程。协同模式在这里的价值还体现在评审环节：评审角色会指出 lambda 可读性较弱，如果团队规范不允许复杂逻辑放在 lambda 中，可以进一步改为具名函数或规则类。测试角色同时运行五个等价性用例，确认返回值和原始实现完全一致后，重构才被接受。

规则表版本也存在取舍。它把条件判断数据化，但增加了一层间接调用，单次计算可能多几个函数调用开销。对于订单折扣这种低频逻辑，这个开销可以忽略；但如果该函数位于高频热路径，评审角色可以要求保留原始判断结构，只做提取常量和小范围去重。协同模式并不是强制生成某一种风格，而是在约束下找到行为等价且可维护性更好的实现。

四、落地协同模式时的关键约束与效果评估

协同模式要发挥作用，前提是提供足量的代码上下文。规划角色至少需要目标函数的 AST 切片、调用方列表、相关测试文件和最近提交差异。上下文不足时，评审角色无法判断副作用，测试角色也无法补出有效用例。实际落地时可以先从单个函数或单个模块开始，一次只解决一个明确问题，避免跨模块大改导致计划过于发散。

控制改动范围同样重要。可以在计划中限制允许修改的文件列表，要求不改变公共接口，不调整数据库结构。这样做既能降低回归风险，也能让评审角色集中精力检查业务语义。评估效果时，可以对比单 Agent 重构与协同模式重构在测试通过率、圈复杂度下降幅度、人工回退率上的差异。一般来说，协同模式会增加模型调用次数和整体耗时，但回归拦截率会更高，人工修正成本更低。

下面是一个简化的对比视角：

协同模式不是万能的，它更适合那些存在隐性业务规则、分支复杂、测试基线薄弱的代码。对于简单函数或独立脚本，使用单 Agent 一次性生成反而更高效。判断标准可以简单概括为：如果一个优化任务需要同时平衡多个约束、验证多个边界条件，并且错误成本较高，就值得引入协同模式。最终目标不是让模型调用更多次，而是让复杂代码优化的每一步都可追踪、可回退、可验证。