Claude 4 上线后，最容易传播的是“更强”“重写架构”这类大词。可供开发者判断的信息其实更具体：Anthropic 推出了 Claude Opus 4 和 Claude Sonnet 4，重点放在编码、高级推理和 Agent；两款模型还支持 Extended Thinking with tool use，目前标注为 beta，可在延展思考过程中使用 Web Search 等工具。
AWS 官方博客也确认，两款模型已经可以通过 Amazon Bedrock 使用。对于正在搭建 Agent 的团队，这些变化比笼统的架构标签更值得关注。
最值得看的，是“思考时调用工具”
许多 Agent 仍像一条接力流水线：模型先输出计划，应用程序解析内容，再调用搜索或其他外部工具，最后把结果送回模型。每多一道交接，就多一个出错点，包括参数错误、重复调用、上下文丢失和失败后的状态恢复。
根据 Anthropic 的发布说明，Claude 4 可以在 Extended Thinking 过程中使用工具。以网页研究任务为例，模型可以先判断缺少哪些信息，调用 Web Search，读取返回结果后继续推理。推理和工具执行由此可以在同一任务中交替进行，不必完全依赖预先写好的固定步骤。
这项能力没有让应用层编排消失。模型仍可能选错工具、提交错误参数，或者过度相信搜索结果。工具定义、访问权限、超时、重试和任务状态依然需要开发团队处理。Extended Thinking 提高了 Agent 自主完成长任务的空间，但无法替代运行时控制。
Opus 4 和 Sonnet 4，要拿真实任务来分
AWS 将 Claude Opus 4 称为 Anthropic 迄今最先进的模型，并强调它适合构建复杂 Agent，可在较少监督下完成推理、规划和执行。这一定位让 Opus 4 值得优先进入复杂任务测试，却不足以证明所有业务都该使用它。
Sonnet 4 同样面向编码和高级推理。仅凭发布说明，也得不出一套适用于所有公司的性价比结论。一次任务会消耗多少资源，往往还取决于工具调用次数、失败重试和上下文长度。
更可靠的选型方法，是让两款模型在相同权限和工具配置下完成同一批内部任务，重点记录：
- 任务能否完整结束，结果是否可用；
- 是否出现无效、重复或越权的工具调用；
- 失败后能否恢复，需要多少人工介入；
- 延迟和实际使用成本能否接受；
- 执行过程是否留有可审计记录。
完成这轮测试后，再按任务难度和风险设置路由。规则清楚、结果容易校验的任务可以继续使用现有模型；复杂代码修改、多工具协作等任务，再根据实测结果分配给 Sonnet 4 或 Opus 4。涉及写入数据、合并代码和对外发布的操作，应保留人工确认。
Bedrock 解决了接入入口，上线治理仍要自己做
Claude Opus 4 和 Sonnet 4 已在 Amazon Bedrock 可用，这给现有 AWS 用户提供了直接评估模型的入口。不过，模型能够接入服务，只代表第一步已经完成。
Agent 的风险往往来自执行动作。一个回答错误的聊天机器人可能只会给出坏答案，一个拥有工具权限的 Agent 则可能把错误带入代码库、业务系统或外部渠道。正式上线前，至少要明确工具白名单和最小权限，并保存每次调用的输入、输出与错误信息。
超时、重试和人工接管也要在应用层提前设计。尤其是可能产生重复写入的操作，不能把重试简单交给模型决定。审计记录同样不应只保留最终答案，模型调用了什么工具、使用了哪些参数、在哪一步失败，都需要能够回看。
“多模态原生”暂时不该当成结论
现有可引用资料明确提到了编码、高级推理、Agent 和 Extended Thinking 工具调用，但没有给出足够的底层架构说明。把 Claude 4 进一步描述为依靠“多模态原生架构”，并断言视觉、音频和结构化数据已经在同一推理链中完成统一对齐，依据并不充分。
产品能力可以通过任务测试验证，架构口号则很难直接转化为采购和开发决策。对 Agent 团队来说，先调整评测和运行时控制，比立刻重写整套技术栈更实际：用真实任务比较 Opus 4 与 Sonnet 4，记录每一次工具调用，再决定模型路由和人工复核位置。
Claude 4 带来的实际变化，是把推理与工具使用接得更紧。Agent 能否稳定进入生产环境，仍取决于权限边界、失败恢复、过程审计和最终验收。
