WorkBuddy连接用友YonSuite：从销售履约Agent到验收落地

上篇WorkBuddy连接用友YonSuite：从架构认知到快捷接入讲完了YonSuite自建应用创建、MCP连接器配置和字段映射。有了这些基础，下面用一个真实案例看完整效果。

某成长型制造企业已上线YonSuite，拥有多个销售组织和多个仓库。日常存在三个高频问题：销售人员常问订单是否审核、是否出库、是否缺货；销售运营每天导出销售订单和库存报表再手工筛选异常；客户催单时，销售人员无法快速判断问题出在库存、信用额度、审核还是物流环节。

项目组先建设一个「销售履约Agent」。员工在企业微信中询问：「查询客户华东鸿盛本月所有未完成订单，说明每张订单卡在哪里。」

落地分三个阶段推进，风险逐步放开。

第一阶段：只做查询。项目组先提供四个只读工具：search_customer、query_sales_order、query_inventory、query_customer_credit。只读接口风险较低，即使Agent理解有偏差也不会修改正式业务数据；同时可以先验证客户匹配、组织权限、商品编码、库存口径和订单状态是否准确。

第二阶段：生成草稿，不直接提交。业务人员提出新需求：根据客户订货表在YonSuite创建销售订单。项目组没有直接开放「创建并审核」，而是拆成prepare_sales_order（生成结构化订单草稿并校验）与commit_sales_order（人工确认后正式写入）。Agent先返回确认信息，再等用户明确确认后才调用写入工具。

确认卡（Agent返回）

客户华东鸿盛有限公司；销售组织华东销售中心；结算月结30天；仓库上海成品仓；商品A 500件含税单价128元；商品B 200件含税单价76元；含税金额合计79,200元。风险提示：商品A可用库存仅380件；当前价格比客户最近成交价高3.2%；客户剩余信用额度不足订单金额。是否继续创建草稿？

第三阶段：事件驱动与定时预警。完成查询和草稿创建后，才增加自动化任务：每天上午检查已审核未出库订单；每天下午检查临近交期但库存不足的订单；信用额度不足时通知销售负责人；销售订单完成后更新跟单表；每周生成履约异常分析。YonSuite开放平台提供企业自建应用事件推送与事件订阅能力，WorkBuddy也支持按时间规则执行自动化任务。

这个销售履约Agent，正是本文主张的「私域Agent分工」理念的第一个落地角色。各角色分工设计见上篇01章，多Agent落地节奏见结尾落地清单。

PROMPT 系统提示词 · 销售履约Agent

你是公司的销售履约助理。你的职责是查询YonSuite中的客户、销售订单、库存和信用信息，并向销售人员解释订单当前执行情况。

行为规则：

1. 所有ERP数据必须通过YonSuite工具获取，不得凭空推测。

2. 用户只提供客户名称时，先搜索客户；存在多个候选时列出候选，不得自行选择。

3. 查询库存时必须明确组织和仓库。

4. 「可以销售库存」统一使用可用量，不使用现存量代替。

5. 返回金额时必须同时标明币种和含税/未税口径。

6. 查询结果应标明数据获取时间。

7. 工具返回错误时，如实说明错误，不得生成虚假数据。

8. 未获用户明确确认，不得调用任何写入、提交或审核工具。

9. 不得修改客户信用、商品价格、库存和财务数据。

10. 输出订单异常时，按库存不足、信用不足、待审核、待出库、部分出库、接口异常分类。

NOTE

同一套YonSuite MCP，既可由WorkBuddy原生入口调用，也可由企业自研客户端调用。两者区别在品牌、权限与商业化管控，底座与MCP不变。本文以WorkBuddy为入口示范，若读者自有客户端，只需替换入口层，上篇所述的MCP工具与系统提示词可直接复用。

查询接口可以相对开放，但任何写入操作都必须更谨慎。

第一扇门：准备与提交分离。错误设计是把创建、提交、审核合在一个工具里。正确设计是拆成prepare_sales_order（生成草稿并校验）、commit_sales_order（人工确认后写入）、approve_sales_order（审核）三个不同权限等级。

第二扇门：幂等控制。用户可能连续说两次「确认创建」，网络超时后Agent也可能自动重试。若接口无幂等控制，可能生成两张相同订单。MCP服务在调用YonSuite前，应先检查该幂等键是否已成功执行。

第三扇门：人工确认。确认信息不能只写「是否确认创建」。应当展示客户、组织、仓库、商品、数量、单价、税率、币种、总金额、交货日期、信用风险、库存风险与特殊条款。对于付款、凭证、价格调整、库存调整等高风险操作，建议保留YonSuite原有审批流程，Agent只负责准备数据和发起流程。

写入接口不能无脑重试。查询接口可自动重试，写入接口必须同时具备幂等键、外部单号、执行状态查询、超时结果核验与重复数据检查。

安全门之外，生产运行还需要三道兜底规则。一是批量熔断：连续5条同步失败自动终止任务，推送IT告警，防止一个异常堵住整个队列、反复重试把ERP打崩。二是宕机续传：ERP宕机时缓存待制单任务，系统恢复后自动补发，不丢单。三是异常定向推送：单据写入失败生成异常工单，精准推送给对应业务负责人。

安全门管住写入风险，下面把查询与写入两端最容易踩的坑一并列出。

前面坑十讲权限、坑十二讲审计。把视角拉到「选哪个底座」，安全要求一致：数据不出域、细粒度权限隔离、全链路审计日志。不同底座在这些维度上的能力差异，以及前置入口是否被厂商绑定带来的隐性风险，后续专文介绍。

NOTE

审计日志中不得明文记录AppSecret、Token、完整身份证号、银行卡号等敏感数据。

Agent项目不能只用「能不能回答问题」验收。建议至少设置六项指标。

验收六指标之外，落地推进也有节奏。一个稳妥的落地顺序是六阶段：第一阶段只读查询（订单在哪、库存多少、客户欠多少）；第二阶段异常分析（为什么不能发货、不能下单、金额对不上）；第三阶段报告与消息自动化；第四阶段草稿生成；第五阶段受控写入（人机确认、幂等、权限、审计完善后）；第六阶段跨系统协同（连接CRM、电商、WMS、MES、银企、数据仓库）。

自动化分三级：一级自动查询并生成报告，风险最低可优先上线；二级自动发现异常并通知人员，由人决定如何处理；三级自动准备业务动作，人工确认后执行。适合自动执行的是日报、库存缺口检查、周报；不适合完全无人值守的是自动付款、删除单据、审核凭证、调整价格、库存调整与关闭大额订单。

一键执行清单