过去谈模型编排，很多时候是在编排文本任务：谁理解问题，谁生成答案，谁做复核。
MCP 和工具调用普及后，链路里多了一类东西：动作。模型不只是生成文本，还可能选择工具、传参数、等待结果，甚至触发下一步操作。
从文本链路到动作链路
以前的链路大概是：
用户问题 -> 检索上下文 -> 模型生成 -> 模型复核 -> 返回答案
工具调用加入后，编排层不能只问“这段文本交给哪个模型”，还要继续问：
这个动作该不该发生？
由谁发起？
谁来校验？
失败后怎么处理？
这就是变化所在。模型编排不再只处理文本流，还要处理动作边界。
MCP 让工具变成可编排对象
MCP 把 AI 系统和外部数据源、业务工具、开发环境连接起来。工具能力能被标准化描述后，编排层才有机会统一管理。
比如可以这样定规则：
- 查询类工具默认只读
- 写入类工具必须人工确认
- 高风险调用前先做权限校验
- 工具返回大结果时先摘要，再交给强模型判断
- 失败路径必须有重试、降级或转人工规则
到这一步，编排逻辑就不只是选模型了：
选模型 + 选工具 + 控制动作边界 + 记录过程
Claude 放在判断点更合适
在工具调用链路里，Claude 不一定适合每一步都参与。
更合理的分工可以是：
- 轻模型：意图分类、短文本改写、固定格式转换
- Claude Sonnet：长文档理解、代码上下文分析、工具结果归纳
- Claude Opus：复杂架构判断、高风险复核、长链路计划拆解
每一步都用最强模型，成本会很快上去。每一步都用轻模型，关键判断又容易不稳。
Claude 更适合放在复杂链路里的判断点，而不是所有步骤的默认入口。
4. 编排层要补三类能力
第一是权限。哪些用户能调用工具，哪些字段可以返回，哪些动作只能读不能写，这些不能只靠 prompt 管。
第二是失败路径。权限不足、参数错误、服务超时、返回为空、结果冲突，都要提前想好：重试、降级，还是转人工。
第三是审计日志。至少要记录工具、参数、结果摘要、模型版本、最终结论，以及有没有触发写操作。
这些能力补上之后，工具调用才不容易变成一堆不可控的自动化动作。
统一入口让编排可维护
工具层可以统一，模型层最好也统一。
147AI 可以放在模型接入入口，统一管理 GPT、Claude、Gemini 等模型调用，把接口兼容、专线优化、人民币结算、按量计费和成本控制放到一起处理。
这样做之后，编排层不必直接绑定某个供应商接口。它可以把“模型选择”抽象成策略：某类任务默认走便宜模型，复杂上下文切到 Claude，调用失败时切备用路径，用量和成本统一记录。
这样一来，“用哪个模型”就不是写死在业务代码里的判断，而是一条可以调整的策略。
结论
工具调用会让模型编排从“文本工作流”走向“动作工作流”。
MCP 负责工具标准化，Claude 负责复杂链路里的理解和判断，统一接入层负责把模型、成本、fallback 和日志管起来。难点不在某一个工具能不能调通，而在整条链路能不能长期稳定。
