上个月接了个外包——帮一个电商团队把他们的单体 PHP 应用拆成微服务。不是什么惊天动地的项目，但正好撞上了一个最典型的 AI 场景：先理解 8 万行遗留代码，然后拆模块、写接口、做迁移、保证不出 bug。按我平时的做法，这种项目我会用 Claude Code 的 workflow 模式：拆成 5-6 个子任务，每个子任务交给一个独立的 Agent 去跑，我在中间当那个「胶水人」。写 Agent 编排脚本、管理上下文、拼接结果——活儿能干完，但每次干完都感觉累的不是写代码，是当乐队的指挥。结果写到一半，GPT-5.6 Sol 发布了。我本来只是想看看跑分——Terminal-Bench 2.1 刷到 91.9%，我知道。但读文档时注意到一行有意思的说明：「Ultra mode — goes beyond a single agent by leveraging subagents to accelerate complex work.」一个 API 调用，模型自己拆任务、自己生成子 Agent、自己并行跑、自己合并结果？我当时的第一反应和大多数人一样：又是营销话术。但反正有 API Key，试试又不会怀孕。然后这一试，就试了一周。这篇文章不是评测，更不是软文。就是一个写代码的人花了一周时间拿一个新技术反复摔打之后的真实记录。有惊艳的地方，也有让人想骂街的地方。自己编排队，我干了三个月先说说我一直以来的做法。不对比你就不知道 ultra 模式解决了什么。我之前做多 Agent 协作，用的是 Claude Code 的 Agent 和 Workflow 工具。流程大概是这样的：# 传统多Agent编排：每个Agent自己写prompt，自己拼结果 agents = [ {"name": "analyzer", "prompt": "分析这段PHP代码的结构..."}, {"name": "splitter", "prompt": "基于分析结果拆分为独立服务..."}, {"name": "migrator", "prompt": "实现XX服务的数据库迁移逻辑..."}, {"name": "tester", "prompt": "为迁移后的代码编写测试..."}, ] results = [] for agent in agents: result = await run_agent(agent["prompt"], context=last_result) results.append(result) last_result = merge_context(results)这套模式的好处是灵活——每个 Agent 的 prompt 可以精确控制，出错了可以单独重跑。但坏处也很明显：编排代码本身就成了一个项目。我那个微服务迁移做到第三天时，编排脚本已经 400 多行了，比业务代码还多。而且
上个月接了个外包——帮一个电商团队把他们的单体 PHP 应用拆成微服务。不是什么惊天动地的项目，但正好撞上了一个最典型的 AI 场景：先理解 8 万行遗留代码，然后拆模块、写接口、做迁移、保证不出 bug。按我平时的做法，这种项目我会用 Claude Code 的 workflow 模式：拆成 5-6 个子任务，每个子任务交给一个独立的 Agent 去跑，我在中间当那个「胶水人」。写 Agent 编排脚本、管理上下文、拼接结果——活儿能干完，但每次干完都感觉累的不是写代码，是当乐队的指挥。结果写到一半，GPT-5.6 Sol 发布了。我本来只是想看看跑分——Terminal-Bench 2.1 刷到 91.9%，我知道。但读文档时注意到一行有意思的说明：「Ultra mode — goes beyond a single agent by leveraging subagents to accelerate complex work.」一个 API 调用，模型自己拆任务、自己生成子 Agent、自己并行跑、自己合并结果？我当时的第一反应和大多数人一样：又是营销话术。但反正有 API Key，试试又不会怀孕。然后这一试，就试了一周。这篇文章不是评测，更不是软文。就是一个写代码的人花了一周时间拿一个新技术反复摔打之后的真实记录。有惊艳的地方，也有让人想骂街的地方。自己编排队，我干了三个月先说说我一直以来的做法。不对比你就不知道 ultra 模式解决了什么。我之前做多 Agent 协作，用的是 Claude Code 的 Agent 和 Workflow 工具。流程大概是这样的：# 传统多Agent编排：每个Agent自己写prompt，自己拼结果 agents = [ {"name": "analyzer", "prompt": "分析这段PHP代码的结构..."}, {"name": "splitter", "prompt": "基于分析结果拆分为独立服务..."}, {"name": "migrator", "prompt": "实现XX服务的数据库迁移逻辑..."}, {"name": "tester", "prompt": "为迁移后的代码编写测试..."}, ] results = [] for agent in agents: result = await run_agent(agent["prompt"], context=last_result) results.append(result) last_result = merge_context(results)这套模式的好处是灵活——每个 Agent 的 prompt 可以精确控制，出错了可以单独重跑。但坏处也很明显：编排代码本身就成了一个项目。我那个微服务迁移做到第三天时，编排脚本已经 400 多行了，比业务代码还多。而且
