工具少、只读为主：平台够用
只做检索、汇总与建议，工具在两三个以内且都是只读接口，成熟平台通常可以覆盖。此时自研的边际价值很低，反而要长期承担模型升级与工具适配的维护工作，投入产出并不划算，团队精力也被占住。
涉及写操作：定制更稳
需要审批、回滚与细粒度审计时，通用平台的权限模型往往不够用。定制可以把动作分级、审批人与日志字段直接做进流程，避免用配置勉强模拟，后期改动也不会牵一发动全身，责任边界也更清晰。
审计要求决定交付形态
金融、医疗等行业对操作留痕有硬性要求，交付方必须能提供日志字段说明与导出方式。若平台无法说明日志存在哪里、保留多久、谁能查看，即便功能可用，也很难通过内部合规评审，最终还是要重做。
团队能力决定能否自研
自研智能体需要工程能力而非算法能力，重点是接口封装、编排与权限控制。若团队已有稳定的后端与运维力量，自研可行；若只有业务人员，建议外部交付并把配置与文档留在内部，逐步培养接手能力。
混合模式与退出安排
常见做法是外部交付首版并移交配置与文档，内部接手日常运营，后续工具扩展由内部完成。合同里应写明配置导出格式与工具接入规范，否则接手时会发现改一处要动全身，只能继续依赖原供应商。
适用与不适用
适合谁
- 在平台采购与定制之间取舍的技术负责人
- 涉及写操作、需要审批与审计的场景
- 已有后端团队、希望逐步内化的企业
不适合谁
- 只需要知识问答、不涉及系统动作的团队
- 无法提供接口文档与测试环境的场景
典型场景
某医疗机构的预约智能体需要读取排班、提交改约并留痕。评估发现通用平台的日志字段不足以满足院内审计要求，最终选择外部交付首版，并要求配置可导出、日志字段按院内规范补齐，上线三个月后由信息科接手日常维护，外部只在工具扩展时提供支持。
可执行步骤
- 统计工具数量与读写类型，判断属于哪一类复杂度，作为选型的第一道筛选
- 评估内部团队是否具备接口封装与长期运维能力，避免上线后无人接手
- 评估内部团队是否具备接口封装与长期运维能力，避免无人接手，避免后期无人接手
- 选择路径并明确配置导出格式、文档清单与移交时间，避免被单一供应商锁定
常见坑
- 用通用平台勉强模拟审批流，配置复杂且难以审计，最终被合规否决，项目整体退回重做；时间与预算双重损失。
- 为只读场景做定制开发，投入大而收益有限，维护成本长期存在，团队还被绑在低价值工作上，后续再谈投入也很被动。
- 合同未约定配置导出格式，接手时发现无法迁移，只能继续依赖原供应商，议价空间随之消失，长期处于被动地位。
- 内部没有后端力量却选择自研，第一版之后无人能改，工具一升级系统就停摆；业务连续性受影响。
自检与验收清单
- 工具数量与读写类型是否已统计，是否有书面结论
- 审计与审批要求是否逐条核对，是否留有核对记录
- 内部团队是否具备接口与运维能力，是否有接手演练
- 配置导出与文档移交是否写入合同，是否约定移交时间
常见问题
平台能不能满足审批需求？
部分平台支持审批节点，但通常粒度较粗，难以按动作类型区分。若审批要求涉及多级、按金额或按角色，建议先做配置验证，再决定是否走定制，避免上线后才发现权限模型不够用而返工。
自研智能体难在哪？
难点不在模型调用，而在工具封装、编排稳定性与权限控制。这些属于工程问题，需要后端与运维配合；只靠算法团队往往做得出演示，做不出可长期运行的系统，最后还是要外部介入收拾。
外部交付后怎么避免被锁定？
把配置导出、接口文档、提示词与评测集写入交付清单，并在项目中期做一次由内部人员独立完成的工具接入演练。演练能提前暴露文档缺口，比事后谈判更有效，也能让团队真正掌握系统。