AI智能体自建还是采购？先算清上线后的成本与分工

欧洲团队想采购一套现成的AI智能体，总部技术团队认为可以自己开发。演示看起来都不错，报价却很难放在一起比较：一边是订阅费，另一边是开发人月。会议开到最后，往往还没说清上线以后谁接手。

假设这套系统负责处理供应商的交期变更。它需要读取订单、识别差异、准备回复，再交给有权限的人确认。平时流程顺畅，但遇到旧附件、订单修改或客户追问时，谁来判断、谁来暂停、谁来补上人工处理？这是一个用于分析的示例，并非客户案例。

如果您正在为奥地利、德国或瑞士的业务选择方案，建议把讨论落到一个具体流程。本文提供三种路径的对照表、运行责任清单和成本核算方法，帮助业务负责人、技术团队与管理层用同一组事实做决定。

先说清任务，再决定是否需要智能体

这里的AI智能体，是指利用模型选择执行步骤和工具来完成任务的系统。如果每一步基本固定，用传统流程编排加一个受约束的AI处理环节，也可能满足需要。

“让AI处理供应商邮件”还不够具体。可以改成：“依据当前订单和已批准的条件，识别供应商提出的交期变化，生成回复草稿，未经指定人员确认不得发送。”这样，输入、结果和权限边界就清楚了。

Anthropic的技术文章区分了预设路径的工作流与由模型选择步骤的智能体，并建议从能够满足需求的简单设计开始。对企业来说，值得先问的是任务需要多少自主性，而不是产品名称里是否带有“Agent”。

写下一次任务从哪里开始、什么结果算合格，以及什么情况下必须交回人工。若这些问题还没有答案，急着比较平台功能，容易把流程本身的分歧带进下一轮采购或开发。

采购、自建和组合，各自留下什么工作？

自建通常是开发自己的应用和流程，并不意味着从零训练大模型。采购也不一定意味着交钥匙运行。第三种选择是采用现成基础能力，再自行设计少数关键环节。比较时，请让三种方案面对同一个业务任务。

在手机上可左右滑动表格，比较三种方案。

表中的判断是架构分析，不是产品排名。现成产品可以承担重要流程，前提是边界和证据足够清楚。自建也可以合理，前提是组织有能力长期运行。组合方案需要额外关注交接处，不能因为每个组件都有供应商，就假定整体有人负责。

把“供应商会处理”改成具体分工

当供应商说“包含支持”时，可以拿一个问题继续问：系统使用了旧订单信息，生成了错误的交期回复。谁发现？谁能阻止发送？等待排查期间，未完成的订单由谁处理？

这些首先是运行安排。合同责任和法律责任需要由相应专业人员审阅，不能仅凭产品功能推断。企业内部同样如此：在表格里填上一个名字，并不意味着那个人有时间、权限和支持条件。

微软关于智能体运营组织的指南把责任归属、决策权限、生命周期与监控作为明确的组织工作。落实到一个流程，您可以先用下面这张清单，而不必立即成立新的部门。

特别注意欧洲业务团队与总部之间的交接。如果批准人在欧洲、技术支持在另一时区，异常队列由谁持续处理？把办公时间、通知方式和紧急权限写进运行安排。是否需要跨境传输、涉及哪些访问路径，则交给隐私和安全负责人结合实际方案核实。

相关控制可以继续参考智能体身份与权限指南以及上线后的监控方法。

报价之外，真正需要比较哪些成本？

先统一时间范围、业务量和质量标准，再比较费用。采购报价如果只含软件订阅，自建估算却包括测试和维护，两者的总价就没有直接可比性。

把一次性投入和持续投入分开。前者通常包括配置、数据整理、系统衔接和验收；后者可能包括平台与模型调用、人工复核、异常处理、维护、监控和实际需要的支持。迁移与退出工作也应单独列出。

每个合格案例的成本＝该期间可归属的运行成本÷达到约定验收标准的案例数。

说明是否分摊了前期投入，避免把同一项维护工作同时计入内部工时与外部服务费。若需要人员待命，即使某个月故障很少，相应安排也可能占用资源。

一个值得实际测量的变量是人工介入。多少案例需要复核？每次耗时多久？高峰期会不会积压？用有代表性的案例记录这些情况，比直接把演示中的速度换算成全年节省更可靠。关于模型调用与合格结果成本的细分，可参考AI任务路由指南。

用同一组案例检验所有方案

回到供应商交期变更的示例。假设订单已经更新，但附件仍是旧版，系统准备发出的回复又包含新的交货承诺。给每个候选方案提供同样获准使用的信息，并要求遵守相同的审批规则。

合格处理应当识别当前记录、说明冲突，并把承诺交给有权确认的人。技术实现可以不同，业务边界必须一致。

1. 检查结果及依据。中文或德文写得流畅，并不能证明采用了正确的订单版本。
2. 检查可执行动作。未经批准，系统能否发送承诺或修改记录？
3. 在安全测试环境中撤销一项权限或中断一个依赖，观察任务怎样停止、交给谁。
4. 做一次受控变更，再运行同一案例，确认谁能发现结果退化。

困难案例用于检查边界，常见案例用于观察日常成本和处理能力。两类都要有。应在比较开始前约定案例集，避免每套方案只展示最擅长的部分。

欧洲业务场景怎样影响选择？

现成产品可能已经能很好地处理文档，但仍需要适应当地团队的审批习惯、德语异常情况或已有业务系统。逐项描述这些需求，再判断能否通过受支持的配置解决。

如果必须增加自有组件，要明确它负责什么，以及它会给升级、排错和交接增加多少工作。“我们需要灵活性”不够具体；“某类订单必须由指定人员确认，而且每次都能查到记录”才是可以验证的要求。

对跨境团队而言，服务商名称和托管区域也不足以说明全部数据路径。支持访问、日志、分包服务和退出后的数据处理，需要根据实际文档核实。这里提供的是架构审查问题，不构成法律合规结论。

把选择推进为一个可完成的工作计划

可以把内部决策工作分成四周，时间根据人员和资料可用性调整。这是一个建议顺序，不是上线承诺，也不是Architecture Mandate的交付日程。

• 第一周：圈定一个流程，确定决策负责人，整理业务量、异常和验收标准。
• 第二周：比较三种路径，完成责任清单，向供应商和内部团队索取缺失证据。
• 第三周：测试代表性案例与恢复过程，用观察结果修正重要成本假设。
• 第四周：由业务发起人组织审议，选择路径并写明条件，或缩小范围、暂缓投入。

做决定前，至少应能说明任务边界、运行负责人、权限限制、成本假设和出问题时的替代流程。关键缺口需要单独处理，不能靠其他项目的高分抵消。

什么时候适合引入Architecture Mandate？

如果团队能自行完成以上比较，而且有足够证据支持决定，可以沿用内部审批流程。若一项重要选择涉及多个团队，而架构、依赖和责任仍无法形成一致判断，外部评估才有明确价值。

Architecture Mandate针对一个优先AI流程进行有明确边界的评估，形成书面决策，并包含商业论证假设及自建、采购或集成建议。标准费用为22,000欧元，不含增值税；满足启动条件后，计划交付期为15–20个工作日。开发实施、供应商采购、托管运行和法律意见不属于标准范围。

初次沟通可先提供非保密的流程说明、待决问题和负责角色。我们先确认任务、证据获取、时间和预算是否匹配，再考虑正式提案。网站提供中文说明；标准项目以英语或德语交付，并按约定提供另一种语言的管理层摘要，其他翻译需另行约定。

了解适用于您这项AI决策的Architecture Mandate

如果已经选定方案，下一步可以阅读从试点走向生产的决策框架，检查进入下一阶段还缺哪些证据。

选择方案前常见的问题

采购AI智能体一定比自建便宜吗？

不能只看订阅费和开发报价。应针对同一流程、时间范围和验收标准，比较前期配置、持续费用、人工复核、维护及退出成本。

自建是否意味着训练自己的大模型？

不是。企业可以围绕外部模型开发自己的应用和流程。需要说清哪些部分由自己控制，哪些能力仍依赖模型或平台供应商。

购买产品后，出错是否都由供应商负责？

运行分工与法律责任是不同问题。先确定谁发现、暂停、复核和恢复流程，再由相关专业人员审阅合同与法律责任。

什么情况下适合组合方案？

现成基础能力适用，但部分关键步骤需要自有行为或控制时，可以考虑组合。必须测试交接，并明确谁负责跨组件的整体问题。

证据不足时，应先选一个方案试着上线吗？

不应把未知当作批准依据。可以缩小范围、保持人工主导，或暂缓投入，同时记录缺失证据及其负责人。

写作说明：对照表与清单属于作者的架构分析，业务情境为示例。技术厂商资料用于提供背景，不代表产品推荐或客户成效证明。资料核查日期：2026年9月20日。