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

销售履约Agent真实案例

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

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

分阶段落地策略

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

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

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

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

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

销售履约Agent系统提示词

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

行为规则：

• 所有ERP数据必须通过YonSuite工具获取，不得凭空推测。
• 用户只提供客户名称时，先搜索客户；存在多个候选时列出候选，不得自行选择。
• 查询库存时必须明确组织和仓库。
• 「可以销售库存」统一使用可用量，不使用现存量代替。
• 返回金额时必须同时标明币种和含税/未税口径。
• 查询结果应标明数据获取时间。
• 工具返回错误时，如实说明错误，不得生成虚假数据。
• 未获用户明确确认，不得调用任何写入、提交或审核工具。
• 不得修改客户信用、商品价格、库存和财务数据。
• 输出订单异常时，按库存不足、信用不足、待审核、待出库、部分出库、接口异常分类。

写入安全三道门

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

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

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

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

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

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

高频技术坑速查

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

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

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

验收标准与落地清单

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

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

此时WorkBuddy不只是一个查询入口，而逐渐成为跨系统任务的统一编排入口。

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

一键执行清单

1. 梳理高频查询场景，圈出每天重复问、重复查、重复整理的三件事。
2. 在YonSuite创建按业务域拆分的自建应用，只申请所需API，禁用管理员账号。
3. 建立接口台账，把原始接口封装为个位数业务工具，明确每个工具的权限与业务口径。
4. 搭建MCP服务，做令牌缓存、统一调用封装、组织权限校验与审计日志。
5. 在WorkBuddy创建自定义连接器，过滤工具权限，先在测试Agent验证。
6. 写入操作拆为准备、提交、审核三道门，加幂等键与人工确认界面。
7. 先上只读查询与异常通知，跑稳后再开放草稿生成与受控写入。
8. 配置系统提示词与知识库，按业务角色拆分多个私域Agent，而非一个超级Agent。

WorkBuddy负责理解人，YonSuite负责执行企业规则，MCP负责控制两者之间的边界。把权限、口径、幂等、审计与审批想清楚，企业Agent才能从一次热闹的演示，变成一套能运行、能审计、能扩展的业务系统。