很多人做 Agent，第一步是写 Prompt。
第二步是加工具调用。
第三步是不断修补边界条件。
但真正上线后才会发现：
Agent 不是一个 Prompt 问题，而是一个系统架构问题。
尤其当模型能力提升到 Claude Opus 4.6 这个级别后，设计方式本身就需要升级。
这篇文章不讨论参数规模，不讲部署细节，只回答一个问题：
当模型具备强规划能力时，Agent 系统应该如何分层？
一、Prompt 驱动型 Agent 的瓶颈
早期 Agent 架构通常如下：
用户输入
↓
拼接 Prompt
↓
模型生成规划
↓
代码解析
↓
调用工具
↓
再次拼接 Prompt
看似可行，但存在明显工程问题：
1. 控制流混乱
模型与代码争夺控制权，边界不清晰。
2. 状态管理脆弱
上下文拼接策略不当时，容易污染任务状态。
3. 扩展性差
增加新模型或新工具时，需要重写流程控制逻辑。
当模型能力不足时，我们必须用代码强行兜底。
但当模型能力足够强时，过度控制反而成为限制。
二、基于 Claude Opus 4.6 的 Agent 分层架构
在实践中，我们逐步形成了一套四层结构：
1️⃣ Task Layer（任务层）
只定义目标与约束，不参与执行。
例如：
- 分析多份财报
- 生成对比报告
- 输出结构化 JSON
这一层只负责“说清楚要什么”。
2️⃣ Strategy Layer（策略层）
由模型主导规划与决策。
Claude Opus 4.6 在这里承担核心角色：
- 拆解任务
- 设计执行步骤
- 判断是否调用工具
- 组织结构化输出
关键变化在于：
不再由代码写死流程，而是允许模型进行高层规划。
3️⃣ Execution Layer（执行层）
纯工具与外部系统调用：
- 数据库查询
- 搜索接口
- 计算模块
- 业务 API
这一层不包含业务决策逻辑。
4️⃣ Orchestration Layer（调度层）
负责：
- 多模型路由
- 失败回退
- 成本控制
- 并发管理
- 日志与审计
这是系统稳定性的核心。
三、完整架构示意（文字版）
User
↓
Task Layer（目标定义）
↓
Strategy Layer（Claude Opus 4.6 规划）
↓
Orchestration Layer（模型调度）
↓
Execution Layer（工具执行）
核心原则：
模型主导规划，系统主导边界。
四、为什么必须显式设计“调度层”？
一旦进入多模型协同阶段，复杂度会迅速上升：
- 不同模型接口不一致
- 错误码体系不同
- 返回结构不同
- 成本结构差异大
如果直接耦合在业务代码中，系统会迅速失控。
调度层的本质是：
把“模型差异”隔离在业务层之外。
在工程实践中，我们更倾向通过多模型聚合接口统一调用模型，例如通过类似 POLOAPI 这样的聚合平台，将不同模型抽象为统一接口。
这样可以实现：
- 同一套 SDK 切换模型
- 模型 AB Test
- 容灾回退
- 成本策略控制
五、Agent 设计逻辑的转向
过去：
模型能力不足 → 代码补强
现在：
模型能力足够 → 系统只做边界与调度
Claude Opus 4.6 的意义，不只是推理能力增强，而是：
它可以承担“策略层”的角色。
Agent 系统因此从“强控制型”演进为“策略驱动型”。
六、工程实践建议
1️⃣ 上下文管理必须模块化
不要把拼接逻辑写死在控制流里。
2️⃣ 模型调用与业务逻辑解耦
否则无法做 AB 测试或快速替换模型。
3️⃣ 调度策略必须可配置
成本阈值、并发限制、降级规则都应可调整。
4️⃣ 日志与审计独立
企业级系统必须可追溯。
七、总结
Agent 不只是 Prompt。
它本质上是一个分层系统。
当模型进入执行时代，真正的挑战不再是“让模型更聪明”，而是：
如何让模型在清晰边界内发挥能力。
模型是大脑。
调度层是中枢神经。
执行层是肌肉。
缺一不可。
