SaaS 智能体自研还是采购？用矩阵决策

SaaS 团队做智能体，该自研还是采购？dev.to 的这篇文章把问题拆成了逐层决策：先划分组件，再用五个问题和加权矩阵比较自研、采购与混合方案。作者提醒，原型容易做出来，生产环境里的评估、监控、安全和持续升级，才是容易低估的开销。

目前能确认什么

作者将智能体拆为模型、记忆、工具、编排、安全约束、评估和可观测性。工具负责连接外部操作，编排负责组织执行流程，评估与可观测性则帮助团队检查效果、追踪运行问题。各层可以分别选型。

决策单位应该是每一层，而不是整个智能体。

五个判断问题分别是：它是否构成产品差异、是否依赖专有数据、变化有多快、失败代价有多大，以及团队能否长期维护。

节选给出的 Python 脚本用权重乘以评分后求和，评分从偏向采购到偏向自研。客服分流示例得到 3.4 分，落在作者设定的混合方案区间。作者也明确表示，重点是让团队解释评分理由。

成本方面，作者要求比较 12 至 24 个月的总拥有成本（TCO）。自研需计入维护、推理、评估监控、安全与机会成本；采购也有集成、定制限制和切换成本。现有节选没有提供完整的成本估算结果。

我的判断

这套方法适合把「我们能做」推进到「谁来长期负责」。例如，涉及退款、修改客户数据的工具层，应先明确权限、审计和审批责任，再讨论框架选择。

矩阵能暴露分歧，但不能替团队证明结论。代码中的阈值是作者设定的，节选没有交代校准依据；团队若对维护能力判断过于乐观，算出来的分数也会偏向自研。

采购是否省维护，要看供应商实际承担了哪些工作。

具体平台覆盖哪些评估、安全和升级责任，仍需官方文档确认。原文后续的失败案例与完整成本比较，也尚未出现在现有材料中。