深圳的制造、贸易和零售企业来聊 Agent 定制开发，问得最多的其实是两句话：「多久能上线」「怎么算验收通过」。优码云（umayun）以深圳为基地，交付范围覆盖粤港澳大湾区，也承接全国远程项目。这篇文章不谈报价，只讲交付：一个企业级 Agent 从立项到灰度上线，每一步交出什么、验收数字怎么写进合同、哪些坑几乎每个项目都会踩一遍。
先把边界说清楚。我们说的 Agent 定制开发，是把大模型接进企业已有的 ERP、CRM、工单或知识库，交付一个可评测、可回滚、带人工兜底的生产功能，而不是一份演示 Demo。深圳本地软件开发的交付规范与能力模型，可以参考站内的深圳软件开发专题页。
哪些场景值得先做 Agent：先用三个筛子打分
不是所有流程都适合交给 Agent。我们在需求切片阶段只用三个筛子打分：数据可得性、容错度、调用频次。
- 数据可得性：要处理的数据和要调用的系统，接口是否已经存在、能不能被程序稳定调用。
- 容错度：做错一次，代价是否可逆、能不能靠人工兜底修正。
- 调用频次：这个任务每天的量级，是否足以摊薄开发与推理成本。
每项按一分到五分打分。总分高，才值得先做 Agent；但只要「容错度」低于三分，也就是错一次代价不可逆，无论总分多高，都应该先上规则引擎或 RPA，而不是 Agent。
| 候选场景 | 数据可得性 | 容错度 | 调用频次 | 建议 |
|---|---|---|---|---|
| 售后工单分类并草拟回复 | 高 | 中（人工复核后发送） | 高 | 优先做 |
| 客服知识问答 | 高 | 中 | 高 | 优先做 |
| 合同关键条款抽取 | 中（历史多为扫描件） | 低（错漏有法律风险） | 中 | Agent 只做辅助，主流程走规则 |
| 库存对账异常归因 | 中 | 中 | 中 | 可做，先跑离线批处理 |
| 财务付款审批 | 低 | 低 | 低 | 不做，坚持规则引擎 |
把这张表填满，通常比谈十轮需求更能决定一个项目该不该做。
五步交付流程：Agent定制开发每步的交付物与签字人
确认要做之后，我们按五步推进，每一步都有明确的交付物、签字人和周期量级。周期口径来自站内案例页面里记录的「首版」量级，多数项目集中在数周到十余周之间；具体到单个项目仍取决于接口数量和权限审批链条。
| 步骤 | 交付物 | 谁签字 | 周期量级 |
|---|---|---|---|
| 一、需求切片 | 目标场景清单、成功定义、边界外清单 | 业务负责人 | 数天 |
| 二、数据与工具接入 | 接口清单、权限矩阵、脱敏方案 | 业务负责人 + IT/安全 | 一到数周 |
| 三、单场景 pilot | 可运行原型、失败样本集、兜底路径 | 业务负责人 | 数周 |
| 四、评测集与验收指标 | 冻结版评测集、指标看板、验收口径文档 | 业务与技术双方 | 与 pilot 交叠 |
| 五、灰度上线与交接 | 灰度方案、回滚预案、Runbook 与运维交接 | 双方项目负责人 | 数周 |
第一步最容易被跳过，也最容易在后期反噬。把「这个 Agent 不做什么」写下来并由业务签字，比把「它能做什么」写漂亮更重要。
第二步的产物不是代码，而是一张权限矩阵：每个工具、每个数据表，Agent 在哪个环节读、哪个环节写、写完谁来复核。下面第三节的三类踩坑，有一类就出在这里。
第四步的评测集不是测试同学的临时脚本，而是双方共同确认、冻结版本、可追溯的资产。腾讯云开发者社区一篇 2026 年 7 月的评测实战文章引述 Gartner 调研：76% 的 Agent 项目因缺乏系统化评测体系而在 UAT 阶段返工超 3 次，平均延误交付 4.2 个月。
该文给出的第一条铁律就是「评测数据集必须版本化、可追溯」，第五条是「质量门禁必须自动化、不可绕过」。原文见腾讯云开发者社区。
验收标准写进合同：四类指标与评测集怎么造
验收条款如果只写一句「回答准确率达标」，几乎必然在验收阶段扯皮。我们建议把这四类指标连同计算口径一起写进合同。
- 任务成功率：在冻结评测集上，Agent 端到端完成并输出可交付结果的占比。要写清楚「完成」的定义——是产出草稿，还是产出可直接对外发送的终稿。
- 人工兜底率：需要人工介入才算完成的比例。这个数字直接决定上线后的人力投入，比成功率更该被关注。
- P95 响应延迟：取第 95 百分位的响应时间，而不是平均值。平均值会把长尾问题藏起来，而用户体验由长尾决定。
- 单会话成本上限：每一次会话的模型与工具调用成本上限，超过要有降级策略。这是 Agent 项目最容易失控的一项。
四类指标都要在评测集上算，所以评测集怎么造，比指标名本身更重要。做法是从真实工单或真实会话里抽取样本，覆盖高频场景、边界场景和对抗样本三类。
规模上，数十到上百条真实样本通常就足以暴露主要问题，关键不是数量，而是分布。样本要脱敏、要冻结版本、要保留来源出处；任何一次模型或提示词改动，都跑同一套评测集做回归。
一份由 CSDN 技术社区发布的 Agent 工程学习文档，把「只看准确率不看成本」列为典型坑：换模型后题面通过率只小幅上升，单任务成本却成倍膨胀（见该文档）。只盯成功率的验收条款，恰好会漏掉这一项。
三类常见踩坑复盘
踩坑一：工具权限一开始给太大
某制造类客户的项目，pilot 阶段为了「省事」，直接给了 Agent 对生产库的写权限。一次提示词调整后，Agent 把测试数据写进了正式表，虽然当天回滚，但内部信任度受挫。
正确做法是把权限按最小可用给：先只读，写操作走「草稿 + 人工确认」通道，等评测集跑稳、人工兜底率降下来，再逐个放开写权限。权限矩阵在第二步就该签掉。
踩坑二：评测集与生产分布不一致
某贸易类客户的评测集，用的是整理得很干净的 Excel 工单，而线上真实工单里有大量语音转文字的口语化描述。评测集分数很漂亮，上线后人工兜底率却明显偏高。
原因不是模型变差，而是评测集的分布和生产不是一回事。评测样本必须来自真实渠道，包括那些「不规整」的输入，并定期从线上补充新出现的样本。
踩坑三：上线后模型版本漂移
某服务类客户的项目上线数月后，上游模型供应商更新了默认版本，同一个提示词下 Agent 的行为出现变化：格式更松、偶尔跳过校验步骤。
对策是把模型版本钉死，并在合同里写明变更流程：版本升级必须走回归评测集，通过门禁才能切换，同时保留一键回滚到旧版本的能力。模型不是一次性交付物，它是一个需要持续运维的依赖。
驻场（FDE）还是远程交付
驻场交付（Forward Deployed Engineer，FDE）指工程师进入客户现场，与业务方坐在一起迭代；远程交付则是通过固定节奏的线上评审推进。两者不是谁更高级，而是适配不同项目形态。
- 适合驻场：业务流程复杂且没被写下来、需要频繁找一线员工确认细节、跨多系统集成、上线窗口紧张的项目。深圳及大湾区客户当天往返，驻场协调成本相对可控。
- 适合远程：场景边界清晰、接口文档齐全、双方都有技术对接人、以离线批处理为主的项目。全国远程项目多属这一类。
很多项目是混合模式：前期的需求切片和 pilot 阶段驻场，进入评测与灰度阶段转为远程。决定模式的关键不是预算，而是「有多少业务知识只存在于一线员工脑子里」。
开工前自查八问
立项前，把这八个问题当面问一遍，答不上来的先别开工。
- 这个场景的数据和工具接口，现在是否已经存在？
- Agent 做错一次，最坏结果是什么，可不可逆？
- 「完成」的判定标准是什么，谁来判定？
- 上线后需要人工兜底的比例，业务方能接受多少？
- 评测集从哪里来，谁负责提供真实样本？
- 模型版本由谁锁定，升级走什么回归流程？
- 灰度上线先放多少流量，回滚由谁决策？
- 上线三个月后，这套系统由谁运维、预算归谁？
八问都能给出明确答案，项目通常就能顺利推进。想进一步了解 Agent 定制开发这类项目的交付方案，可以看智能体定制开发方案页，或直接联系我们做一次需求切片；已交付项目的页面记录整理在客户案例。
常见问题
Agent 定制开发的交付周期一般多久？
取决于接口数量和权限审批链条。从站内案例页面记录看，首版量级多集中在数周到十余周；需求切片和单场景 pilot 通常占掉前半段，评测与灰度占掉后半段。
智能体项目的验收标准应该由谁定？
指标口径由业务方和技术方共同确认：业务方负责定义「什么算完成」，技术方负责定义「怎么测」。两者都要签字并写进合同。
深圳的 AI Agent 开发公司，驻场一定更好吗？
不一定。业务知识越依赖一线员工、系统集成越复杂，驻场价值越大；边界清晰、接口齐全的项目，远程交付效率更高，成本也更低。
验收时只测准确率行不行？
不行。至少还要覆盖人工兜底率、P95 响应延迟和单会话成本上限，否则会出现「指标好看但成本失控」的情况。本文的问答仅作说明，Google 官方生成式搜索指南已明确 FAQ 富结果不再展示（参见官方说明）。