售前助手要查订单，客服助手也要查，分析助手还要按月份汇总。三个项目各自接了一遍订单系统。后来接口改了一个字段，三组人分别修复；更麻烦的是，同样叫“订单金额”，有的返回含税价，有的已经扣除了退款。
这部分工作并不需要每个 Agent 重新实现。先对照现有代码，找出真正相同的一项操作，例如按订单编号返回订单状态和允许查看的金额。汇总分析需要另一种输入和权限，不能仅因为都涉及订单，就塞进一个什么都能查的工具。
如果已有内部 API 或 SDK 已经统一了这些规则，继续用它。需要补上的可能只是让不同助手找到并使用这个入口，而不是再写一个订单服务。EasyNet 的用途在于把这种已维护的操作接给不同调用方，不是替换团队已有的业务系统。
对于仍散落在脚本里的实现，可以由订单系统的维护者选定一个函数，通过 EasyRemote 接入；已有服务则保留原有接口和维护方式。函数描述要说清输入、金额口径、失败原因和负责人，再为需要使用它的助手配置支持的调用入口，例如 MCP。
共享实现不能变成共享超级账号。客服能查哪些客户，分析助手能取哪些字段，仍要由提供方依据可信的调用身份检查。助手在参数里声称“我是管理员”不构成授权，工具说明写了“只读”也不能代替底层账号和业务代码的限制。
先让两个现有项目使用同一个查询，分别测试正常订单、无权查看的订单和业务接口不可用的情况。也要检查助手是否理解结果：接口返回的是含税总额，就不该在回答里说成已到账收入。运行结果一致与业务解释正确，需要分别验证。
如果下次接口变化只需维护者修一次，两个项目仍能得到同样含义的结果，复用才真正成立。团队少维护的是重复的业务连接和规则；每个助手仍需完成自己的连接配置、身份授权和任务测试。
- 01
固定业务含义
金额是否含税、状态来自何处。
- 02
连接维护好的函数
实现与上游凭证由提供方维护。
- 03
两个项目复用
同一语义，不同授权范围。
不要只返回一个没有含义的金额
虚构的订单结果示例，展示字段口径；不是实时订单。
{
"order_id": "demo-42",
"status": "shipped",
"total": {"amount": "108.00", "currency": "USD", "tax_included": true},
"metric": "order_total_not_booked_revenue"
}预期结果：销售与分析不会把同一108美元误当作两种指标。
接入时的检查项
- 两个消费者调用同一业务实现并获得一致语义。
- 权限不同的消费者返回范围确实不同。
- 业务接口变更能通过共同契约测试被发现。