AI agent 不再单打独斗：规划交给大模型，执行交给小模型

AI 辅助开发里我们越来越擅长：给 agent 一个仓库和一个问题，让它自己搞明白。agent 能探索代码库、理解依赖、改代码、跑测试、解读失败、继续干到出结果。这已经改变了开发者的角色。

但底下还有另一层变化：最有能力的模型不必做所有工作。 一个近期的做法很有代表性：用强大的 frontier 模型理解问题、产出实现计划，再让更小或本地的编码模型执行实现。乍看这是省推理成本——确实省。但作者认为它揭示了 agentic AI 更本质的走向。

让一个 agent 干所有事的毛病

agent 收到"加客户通知"这类请求，其实不是让它写几行代码。写任何有意义的东西之前，它得先理解代码周围的系统：客户在哪表示、变更怎么传播、现有什么消息基础设施、业务逻辑在哪、用什么持久化、现有应用遵循什么约定。然后还要做决策：通知同步还是异步？新服务还是并入既有域？投递失败怎么办？重复事件怎么处理？复用哪些抽象？

做完这一切，实现才相对直接。

这些活动需要完全不同的能力：理解陌生架构是推理问题；架构已定后新建一个 repository 类基本是执行问题。单 agent 让同一个模型同时干两种活。这不一定是错的——frontier 模型越来越能干——但也不一定是最有效的架构。

计划改变问题

设想第一个 agent 已经探索完仓库、产出详细实现计划：找到了客户域、事件设施与事务边界，决定通知能力属于某个既有 bounded context，指明哪些组件要改、顺序如何。现在执行 agent 面对的是明确的规格而不是模糊的目标——推理负担被移走，剩下的执行可以被更小、更便宜的模型可靠完成。这是"计划者 + 执行者"的分工，也是成本与可靠性同时改善的方向。

实践建议

• 复杂任务拆"规划代理 + 执行代理"：frontier 模型做架构理解与计划，小模型按规格执行；
• 计划要具体到 bounded context、组件清单与改动顺序，否则小模型又会退回猜；
• 用探针验证执行质量，让规划层能迭代修正，而不是一次下达永不回看。

来源：What Happens When AI Agents Stop Working Alone? - DEV Community