给智能体接能力，用的是自家内部工具还是第三方外部 API？先把结论摆出来：核心业务逻辑、涉及私有数据的，自己做内部工具；通用能力、别人做得已经很好的，直接调外部 API。省事与可控很难两全，选哪个取决于这一环出问题你赔不赔得起。
结论先行：看你要可控还是要省事
内部工具的最大好处是可控：逻辑自己写、数据不出门、想改就改。代价是从头造，维护也是自己的事。外部 API 反过来，接上就能用，升级有人管，但对方改接口、限流、停服，你只能被动跟着调整。把核心链路押在外部 API 上，等于把命脉交了一半出去。一个折中办法是加一层薄封装：外部 API 的调用统一走自己的接口层，换供应商、加缓存、做降级都在这层做，业务代码不直接碰第三方。
两种接法的差别集中在五处，并排看更清楚：
| 维度 | 内部工具 | 外部 API |
|---|---|---|
| 可控性与代价 | 逻辑自己写、数据不出门、想改就改，代价是从头造、维护自负 | 接上就能用、升级有人管，但改接口、限流、停服只能被动跟 |
| 稳定性责任 | 慢了错了责任在自己，排查路径全在自家代码里 | 只能看对方状态页和公告，能做的常常是等，须预设降级方案 |
| 版本演进 | 自己排期，先在测试环境跑稳再上 | 对方说了算，通知了就得跟，静默变更更麻烦 |
| 排查路径 | 从输入、代码到输出一路都能翻 | 中间过程是黑盒，手里只有请求和响应，靠自留日志 |
| 数据与权限 | 按最小可用给权限 | 数据要发给第三方，先过数据分级，用独立密钥和额度 |
稳定性责任落在谁头上
内部工具慢了、错了，责任在自己，排查路径全在自家代码里。外部 API 出问题，你只能看对方的状态页和公告，能做的常常是等。所以接入外部 API 时要预设降级方案：调不通时走什么备用路径，超时多久放弃，这些都要提前写好，不能裸奔上线。版本演进也是责任的分水岭。内部工具升级由自己排期，先在测试环境跑稳再上；外部 API 升级由对方说了算，通知了就得跟，没通知的静默变更更麻烦。接入前留好兼容性检查，响应结构不对就快速失败并告警，能把静默变更的杀伤压到最小。
出问题时排查路径大不同
内部工具出问题，从输入、代码到输出一路都能翻，定位靠自己的记录。外部 API 出问题，你手里只有请求和响应，中间过程是黑盒，这时调用前后的自留日志就是唯一线索，怎么留、留什么，见 执行日志和审计日志有什么区别？。失败之后的恢复动作也分场景，回滚和补偿有什么区别？分界点在哪 给了判断框架。
数据边界与权限先想清楚
外部 API 意味着数据要发给第三方，发什么、发多少，先过一遍数据分级再决定。秘塔AI搜索这类搜索接口拿到的是查询词，风险不大；但把客户资料整段塞给外部接口就要慎重。权限同样如此：内部工具按最小可用给权限，外部 API 用独立的密钥和额度，出事时不至于牵连全身。账单口径也要提前约定：外部 API 多按调用量计费，峰值期费用会放大，内部工具的成本则主要摊在人力上。两种成本曲线不同，预算方式也不同，混着算容易在月底吃惊。
提示词层面的固定与拼装问题也和工具来源相关，固定提示词和动态拼装有什么区别？ 有展开；执行策略上，依赖外部 API 的任务更适合边走边看，理由在 规划先行和边走边看有什么区别？。
接入方式对照表
- 私有数据、核心逻辑：内部工具
- 通用能力、成熟服务：外部 API
- 外部 API 必配：超时、降级、独立密钥
核心的握在自己手里，通用的交给专业服务，别反着来。
拿常见组合举例：用扣子搭流程，搜索能力接外部接口，而跟订单库打交道的那段逻辑自己写成内部工具，各取所长。大模型本身选豆包还是通义千问都行，工具这一层的内外之分才是架构问题的关键。
关于内部工具与外部API，问得最多的三个
- 外部 API 涨价了怎么办？：接入时就把替代成本想清楚，核心链路留一个可切换的抽象层，换供应商不伤筋动骨。
- 内部工具一定要做得多完善？：够当前链路用就行，别为想象中的需求过度建设，接口留好扩展点即可。
- 两者能混在同一个智能体里吗？：能，而且常见，关键是调用日志里能分清哪次走了哪条路。
