浙江与杭州企业在采购外部团队的 AI 智能体（AI Agent）定制开发服务时，最常见的落差往往发生在**“演示效果惊艳，一进内网就瘫痪”**：供应商在售前演示时，智能体查天气、写周报、调用演示 API 顺畅自如；然而一旦接入企业真实的 CRM、ERP、工单系统与财务流程，立刻暴露出死循环调用、越权泄漏客户数据、网络抖动导致的重复下单与工单混乱，最终项目停滞、无法通过验收。
事实上，能写几行 Prompt 拼装一个套壳对话 Demo，与能交付一套可工业级稳定运行的企业 AI 智能体系统，存在着巨大的工程鸿沟。Anthropic 在权威工程实践 《Building Effective Agents》 中明确强调：真正可靠的智能体系统依赖清晰的确定性工作流、严谨的工具契约与健全的评估防护，而非盲目堆砌复杂的自主代理框架；OWASP 也在 Top 10 for LLM Applications 中将过度代理（Excessive Agency）列为关键系统风险。
本文结合小火堆科技在企业级 AI 软件定制与 FDE（驻场前线工程）模式 中的实战经验，为企业决策者与技术负责人梳理采购 AI 智能体开发服务时必须穿透核查的 6 项核心交付能力清单 与 4 个现场穿透提问。
一、 为什么“Demo 演示能跑”不等于“企业级可交付”？
很多开发团队习惯使用 Dify、Coze 或原生 LangChain 的默认模板，为企业搭建一个聊天窗口，并在后台挂载几个大模型接口。这种模式在概念验证（POC）阶段非常快，但在真实企业级业务中，必然遭遇以下三大工程暗礁：
- 大模型的“概率性”遭遇企业业务的“确定性”： 企业业务规则（如财务报销审批流、价格折扣阶梯、库存扣减顺序）要求 100% 确定性，容不得半点偏差。如果把整个执行链路全权交由大模型自主规划，模型偶发的上下文幻觉就会导致跳过前置审批、擅自修改订单状态。
- 缺乏服务端鉴权，引发数据穿透风险： 很多外包系统为了图省事，给智能体配置了一个持有全局最高权限（Admin）的服务端 Token。智能体仅凭用户聊天提示词判断该不该查，一旦被提示词注入或越权诱导，普通销售就能轻易查出全公司的底价与工资表。
- 缺乏幂等设计，网络抖动导致灾难性重复写入： 与只读查询不同，智能体执行“创建商机、扣除积分、发送采购单”等写操作时，若遇到大模型生成超时或网络抖动，盲目重试会导致业务系统生成重复订单或重复扣款。
因此，企业在选型和采购时，必须核验供应商是否具备真正的企业级后端工程能力。
二、 采购 AI 智能体开发服务的 6 项能力审查清单
下表汇总了企业在供应商评审与方案比选时，应当逐项对照的 6 项关键能力要求：
| 审查维度 | 表面 Demo 做法（不可交付） | 企业级工程做法（建议采购标准） | 关键核查依据 |
|---|---|---|---|
| 1. 架构分流 | 全流程交给大模型自主发挥，由 LLM 决定下一步怎么走 | Workflows + Agents 分流架构：确定性业务逻辑用状态机代码写死，仅在感知与意图槽位调用大模型 | 架构设计文档、核心流程图 |
| 2. 工具契约 | 自然语言描述工具，后端无严格参数类型校验 | 强类型 JSON Schema + 服务端白名单防御：参数在进入业务系统前必须经服务端校验通过 | API 接口文档、参数校验代码 |
| 3. 权限隔离 | 智能体使用全局 Admin 密钥，由 Prompt 约束数据可见性 | 最小特权原则 + 穿透式服务端鉴权：终端用户 Token 穿透鉴权，严格执行行级/列级数据权限隔离 | OWASP LLM06 规范、鉴权架构 |
| 4. 容错与幂等 | 失败简单重试，无循环步数上限与防重控制 | 最大循环步数限制 + 写入接口幂等唯一键（Idempotency Key）：超时自动熔断并通知人工复核 | 异常处理时序图、幂等实现机制 |
| 5. 准出验收 | 仅凭“人工试聊几次感觉不错”作为交付标准 | 自动化评测金标集（Golden Dataset）：20-50 个包含正常、缺参、越权用例，设定量化准出及格线 | 评测数据集、自动化测试报告 |
| 6. 资产所有权 | 依赖供应商专有云平台或黑盒镜像，源码不开放 | 完整交付可编译源码、模型配置文件、接口协议与部署脚本，支持后续独立二开 | 合同交付物清单、知识产权条款 |
1. 架构能力：确定性工作流与大模型生成的分流设计
优秀的企业级智能体系统，往往遵循 “确定性优先，大模型后置” 的原则。
- 不合格的交付：把一长串复杂的企业业务流程（例如“收到客户询价 → 提取客户名称 → 校验客户信用 → 计算阶梯折扣 → 触发审批 → 发送报价邮件”）全部写进一个系统 Prompt 里，让大模型自主决定调用哪一步。这种做法极不稳定，任何一个步骤的模型输出波动都会造成流程断裂。
- 合格的交付：将主干流程使用可靠的代码状态机（Orchestrator Workflow）固定下来。大模型仅作为特定节点的“智能解析器”（例如从客户非格式化邮件中提取意图与询价明细），一旦数据被解析为标准 JSON 对象，后续的信用校验、审批分支和邮件发送完全由确定性业务逻辑执行。
企业应要求供应商在方案中清晰标明：流程中的哪些节点由确定性程序驱动，哪些节点由大模型驱动。
2. 工具契约能力：Agent-Computer Interface（ACI）强类型防御
智能体与外部系统的交互必须通过标准化工具（Tool / Function Calling）。
- 不合格的交付：只在 Prompt 里写“如果你需要查库存，请输出 query_stock”。没有参数类型约束，大模型可能会传字符串格式的日期、负数的库存量或带有 SQL 注入特征的查询条件。
- 合格的交付：为每一个工具定义严格的 JSON Schema，并在智能体后端服务中建立严格的反序列化与白名单拦截器。如果大模型传入了非法格式的参数，系统在第一道防线直接报错或追问用户，绝对不将脏参数传递给企业底层的 ERP 或 CRM 核心系统。
3. 安全合规能力：杜绝 OWASP LLM06 过度代理（Excessive Agency）
企业数据的安全性与权限边界是不可妥协的底线。
- 不合格的交付：系统后端配置了一个超级数据库账号或通用 API 密钥。当业务员向智能体提问“帮我查一下上个月华东大区的毛利总额”，智能体拿着超级权限在后台执行了统计并把结果返回给了业务员，形成了严重的越权漏洞。
- 合格的交付：严格遵循最小特权原则（Least Privilege）与完全中介（Complete Mediation）。用户发起请求时，其身份上下文（User Token）必须透传至工具调用的后端系统，由后端数据层执行**行级数据权限（Row-Level Security）**判定。如果该业务员没有华东大区的财务查看权限，底层服务直接返回 403 拒绝访问，智能体据此礼貌回复“您暂无该权限”，彻底杜绝数据越权。
4. 工程韧性能力：接口超时熔断与幂等性写入保障
大模型调用外部 API 时，网络延迟、模型思考超时是不可避免的常态。
- 不合格的交付：智能体在调用“提交工单”接口时发生超时，系统盲目重新触发一次工具调用，导致后台数据库连续插入了两张完全相同的工单；或者大模型陷入死循环逻辑，不断调用同一接口直至耗尽企业 Token 和算力。
- 合格的交付：
- 最大步数限制（Iteration Cap）：限制单次交互的最大工具调用次数（如不超过 5 步），超出后强制熔断并给出友好的转人工提示；
- 业务幂等键（Idempotency Key）：所有非幂等的写操作（创建、修改、扣费、发送）必须生成全局唯一的业务幂等凭证。即便模型因超时发起重试，下游业务系统根据幂等键识别为重复请求，仅返回原处理结果而不重复执行。
5. 准出与评测能力：构建可复测的 Golden Dataset 金标集
在验收环节，最怕双方陷入“你觉得行，我觉得不行”的主观拉锯。
- 不合格的交付：外包人员在上线评审会上演示 3 个精心挑选的提问，回答正确就宣布交付通过。上线后业务人员实际一用，错误率高达 40%。
- 合格的交付：在项目启动之初，由业务方与供应商共同制定 20—50 条业务真实基准用例（Golden Dataset），包括：
- 正常标准场景（60%）
- 缺少关键字段需智能追问场景（20%）
- 超出知识库或权限范围的对抗场景（20%） 每个用例明确标注标准期望输出与工具调用链路。交付前运行自动化测试脚本，必须达到双方约定的准出阈值（例如：工具参数命中率 ≥ 95%、未授权信息拦截率 100%、无依据幻觉率 ≤ 5%）。相关构建方法可参考 《启动企业 AI 试点前需要准备哪些资料？》。
6. 交付物自主权：源码可控与拒绝专有框架绑架
企业采购 AI 服务的核心诉求是形成属于自己的数字资产。
- 不合格的交付：供应商将智能体部署在其私有的云端平台或封装为加密二进制镜像，企业既看不到底层 Prompt，也拿不到工具编排的源码。未来企业想要微调模型、增加一个工具或切换云服务商，必须继续给该供应商支付高昂的维护费。
- 合格的交付：合同明确约定交付完整的应用源码、提示词工程模板、接口适配层代码以及容器化部署配置（Docker / K8s）。企业内部技术团队能够完全接管系统，并具备自主升级与二开的能力。
三、 技术答辩与选型评审时的 4 个“穿透提问”
在与潜在供应商进行方案交流或技术答辩时，企业无需纠缠于“你们支持多少种大模型”这种泛泛的问题，直接抛出以下 4 个穿透性问题，即可迅速识别团队的真实工程深度：
- “如果大模型在调用修改业务接口时，传入了超出权限范围的参数，系统在哪个环节进行拦截？”
- 合格回答：在后端业务服务或 API 网关层通过用户 Token 做鉴权和参数校验，不依赖大模型的 Prompt 自觉；
- 不合格回答：“我们在 Prompt 里明确告诉模型不允许越权了”。
- “如果外部 CRM 接口网络响应超时，智能体发起重试时如何保证不重复创建客户记录？”
- 合格回答：通过客户端生成唯一业务幂等键（Idempotency Key）并在 CRM 写入接口端做防重缓存；
- 不合格回答：“接口一般不会超时，超时了让用户重新点一下”。
- “交付时能否提供一套可以在我们本地或内网流水线一键运行的自动化离线评测脚本？”
- 合格回答：可以提供 Golden Dataset 评测脚本，输出单项准确率与时延统计报表；
- 不合格回答：“上线后你们业务人员多用用，有问题随时在微信群里反馈”。
- “项目结项后，我们如果想将底层模型从公有云模型切换到私有化部署的大模型，需要改动多少核心代码？”
- 合格回答：系统采用适配器模式解耦了模型调度层，仅需修改模型连接配置与 Prompt 模板，不影响上层工具和业务状态机；
- 不合格回答：“我们这个框架跟某个特定平台是深度绑定的，换模型可能需要重新开发一套”。
四、 哪些场景暂不适合直接采用自主智能体？
在决定立项前，企业同样应当保持清醒。如果业务场景存在以下特征，建议先采用 企业知识库问答 或传统的自动化规则引擎，暂缓采购高自主性的 AI Agent：
- 容错率极低的财务核算与核心账务链路：凡涉及资金支付、报税结算且无法容忍任何偶发波动的环节，必须依靠成熟的确定性财务软件与人工复核；
- 业务流程尚未沉淀为规范 SOP：如果企业内部对于某个业务动作由谁负责、如何流转本身就存在多套口径和部门推诿，AI 智能体无法解决管理混乱的问题，只会将混乱放大；
- 缺乏必要的 IT 系统 API 支撑：如果企业的核心系统老旧、不提供任何标准数据接口或只支持无验证的网页点击，智能体调用工具的成本将极其高昂且极易崩溃。
五、 下一步行动与建议
选择一家靠谱的 AI 智能体开发服务商，本质上是选择一家既懂大模型边界、又具备过硬企业级软件工程沉淀的合作伙伴。
若您的企业正在评估业务流程的智能化改造：
- 先从一个痛点明确、具备标准 API 与适度容错空间的业务场景切入，建议先参考 《首个 AI 场景选择方法》；
- 梳理试点任务涉及的系统接口、业务规则与脱敏样本，参考 《启动企业 AI 试点前需要准备哪些资料？》；
- 了解小火堆科技的 AI 智能体开发服务 与 FDE（驻场前线工程）实施方案，我们支持带样本进行技术可行性评估与接口契约审查，帮助企业以严谨的工程标准构建安全可靠的专属 AI 智能体。
