我把微信投诉处理交给了 AI——用 WorkBuddy 造一个处理小程序交易投诉 Agent 的全过程

大家好，我是小悟。

引子：一条投诉的生命周期

运营同学小王每天早上打开电脑的第一件事，是登录微信小程序后台，看看有没有新的交易投诉。投诉来自消费者——商品有瑕疵、物流延误、退款迟迟不到账，各种原因。微信官方给商家提供了完整的投诉处理通道：回应、补证、退款、申诉，路径清晰。

问题出在"清晰"这两个字上。

路径清晰，不代表走起来轻松。一条投诉从到达到关闭，中间至少要经过这些步骤：打开后台、找到投诉列表、点进详情页、读懂当前的状态码（201、106、206、401，每个数字代表一种待办事项）、判断下一步该做什么、手动填好表单或上传图片、提交。

小王一个人管着三个小程序的投诉。高峰期一天能来十几条，每条平均耗时十五到二十分钟。不是每个环节都难，而是每个环节都琐碎，叠在一起就变成了巨大的心智负担。更头疼的是，投诉有时效要求，超过规定时间没处理，小程序的信用分会掉。

"能不能让 AI 帮我处理这些？"

小王问我的时候，我第一反应是：可以，但不是那种"让 AI 帮我写一段话"的方式。我要做的是一个能真正调用微信接口、能读懂投诉状态、能自己判断该走哪条处理路径的 Agent。它不是一个聊天框，而是一个操作助手。

这篇文章记录的就是我用 WorkBuddy 从零造出这个 Agent 的全过程。

一、把问题拆开来看

动手之前，我先把"投诉处理"这件事拆成了三个层面。

第一层是接口层。 微信官方提供了五个投诉处理 API：查询投诉详情、商家回应、补充凭证、提交退款凭证、商家申诉。每个接口都有自己的请求参数、返回格式和前置条件（比如 AccessToken）。这五个接口是 Agent 的"手"——它通过这些接口去触碰真实的投诉数据。

第二层是逻辑层。 每条投诉有一个状态码，决定了当前能做什么操作。状态 201 意味着"等待商家回应"，这时候只能调用回应接口；状态 106 意味着"等待商家补充凭证"，得走补证接口。Agent 需要读懂这些状态码，判断该调哪个接口，然后执行。这是 Agent 的"脑"。

第三层是安全层。 微信的 AppSecret 和 AccessToken 是敏感凭证，不能暴露在 Agent 的运行环境里。所以需要一个中间服务来保管这些凭证，对外暴露干净的 REST 接口，Agent 带上 API Key 就能调用。这是 Agent 的"盾"。

三层各司其职，互不越界。这个思路看起来简单，但它是后面所有代码和配置的根基。

二、为什么是 WorkBuddy

选工具的时候，我考虑过几种方案：直接用 Python 脚本调微信接口、用低代码平台搭一个表单流程、或者找一个 Agent 框架从头写。

前两种做不出真正的"对话式操作助手"。Python 脚本没有对话界面，运营人员不可能在终端里敲命令；低代码平台的表单流程是死的，用户说"帮我看看 12345 号投诉"，它没法理解这句话的意思。

第三种成本太高。我不想花两天时间搭 Agent 的运行时、模型对接、工具调用机制这些基础设施。

WorkBuddy 吸引我的地方在于，它本身就是一个 AI 开发环境，能理解自然语言需求并直接产出可运行的代码和配置。在这个项目里，我需要它做四件事：

1. 研究微信的 API 文档——WorkBuddy 可以直接抓取微信开发者文档的页面，提取接口参数、返回格式、错误码，不用我手动翻文档复制粘贴。
2. 生成完整的可部署代码——从 Agent 配置到 Java 后端到部署脚本，WorkBuddy 能根据需求一次性产出整套项目文件。
3. 设计 Agent 的系统提示词和工具 Schema——这是 Agent 质量的核心，需要把投诉处理的业务逻辑浓缩成 AI 能理解的指令。
4. 迭代和修改——搭建过程中随时调整配置、补充文件、修改代码，不需要切换到其他编辑器。

换句话说，WorkBuddy 在这个项目里扮演的是"全栈开发搭子"的角色：它帮我查资料、写代码、做配置、生成文档，我负责做决策和把关。

三、架构设计：三层分离

整个系统的架构如下面的流程图所示：

图里的关键设计是：Agent 和微信之间永远隔着 Java 后端。Agent 手里只有一把 API Key，它不知道 AppSecret 长什么样，也不需要操心 AccessToken 什么时候过期。Java 服务像一道防火墙，把敏感凭证锁在自己内部，只对外提供六个干净的 REST 端点。

这个设计不是技术上的唯一选择——Agent 完全可以直接持有 AppSecret 去调微信接口。但安全原则上面不该这么做。Agent 的运行环境比 Java 后端更不可控，一旦泄露就是根凭证泄露。多一层代理，多一道防线。

四、在 WorkBuddy 里的搭建过程

4.1 摸清微信的牌面

第一步是研究。我让 WorkBuddy 去抓取微信开发者文档，把五个投诉处理接口和 AccessToken 接口的完整参数提取出来——URL 路径、HTTP 方法、请求头、请求体字段、返回格式、错误码。这些信息是后面所有代码的输入。

WorkBuddy 做了一件让我省了很多时间的事：它不只提取了接口参数，还把每个接口之间的依赖关系整理清楚了。比如，"商家回应"接口需要先有 AccessToken，AccessToken 需要先用 AppID 和 AppSecret 去换；"补充凭证"接口只在投诉状态为 106 时才能调用。这些依赖关系后来直接写进了 Agent 的系统提示词。

4.2 给 Agent 一份"岗位说明书"

Agent 的行为由系统提示词决定。我把这份提示词当作 Agent 的"岗位说明书"来写——它需要知道自己是谁、能做什么、不能做什么、遇到不同状态该怎么引导用户。

核心部分是投诉状态码的对照表：

把这张表写进系统提示词的目的很明确：让 Agent 在拿到投诉详情后，不是把"106"这个数字原样扔给用户，而是主动解释"这条投诉当前需要你补充凭证材料"，然后追问"你想上传什么证明"。

另一个我在提示词里反复强调的规则是：任何写操作执行前，必须先告知用户即将调用的接口和提交的内容，获得确认后再执行。投诉处理是不可逆的——一旦回应提交了，微信那边就记录在案。Agent 可以帮运营人员做准备，但不能替他们做决定。

4.3 让 Agent 学会用工具

Agent 的工具定义在 api-schema.json 里。我设计了六个工具，比微信官方的五个接口多了一个 list_pending_complaints——列出当前所有待处理的投诉单。加这个工具的原因很简单：运营人员最常问的不是"帮我处理某条投诉"，而是"今天有哪些投诉等着处理"。

每个工具的 description 我都写得比较详细，特别是把"这个工具在什么状态下可以调用"写进了描述里。这样做的用意是给 Agent 双重提醒：系统提示词里有状态对照表，工具描述里也有状态约束，两道关卡降低 Agent 用错工具的概率。

工具调用的完整流程如下图：

这张图从运营人员开口说话开始，一路走到 Agent 回复用户结束。中间有四个决策节点：要不要调工具、是不是写操作、用户确认了没有、Token 还有没有效。每一个决策点都是我在搭建过程中反复推敲过的——不是凭空画的，是踩过坑之后总结出来的。

4.4 造一个安全的中间层

Java 后端是这个系统里代码量最大的部分。WorkBuddy 帮我生成了完整的 Java 项目，核心类有四个：

AccessTokenManager 负责 Token 的获取、缓存和自动刷新。它内部用 ReentrantLock 做并发保护，避免多个请求同时去刷新 Token；用 @Scheduled 定时任务在 Token 过期前五分钟主动续期；遇到微信返回 40001 错误码时自动重试一次。这三层保护覆盖了 Token 管理里最常出问题的三个场景：并发刷新冲突、过期未续、刷新后重试。

WeChatComplaintClient 封装了五个微信投诉接口的调用逻辑。每个方法接收业务参数，内部组装请求体、带上 AccessToken、发起 HTTP 调用、解析返回结果。如果 Token 过期导致调用失败，它会触发 AccessTokenManager 刷新后重试。

ComplaintApiController 对 Agent 暴露六个 REST 端点。每个端点在入口处校验 X-API-Key，匹配不上直接返回 401。这层校验是整个安全架构的最外层——没有这把钥匙，Agent 以外的任何请求都进不来。

ComplaintPushService 接收微信推送的投诉回调，存储后通知 Agent。这是"主动推送"模式：微信有新投诉了，Java 后端收到后主动告诉 Agent，Agent 再提醒运营人员"有新投诉来了"。这个模式下，运营人员不需要定时去后台刷新看有没有新投诉，系统会主动找上门。

4.5 把代码打包成可部署的完整项目

这是让我对 WorkBuddy 印象最深的一步。

一开始我让 WorkBuddy 生成的是配置文件和代码片段——系统提示词、工具 Schema、Java 类、环境变量模板。这些文件单独看都没问题，但放到一起的时候，缺少把它们串起来的项目骨架：package.json、tsconfig.json、next.config.mjs、edgeone.json 部署配置、embed.js 嵌入脚本、前端聊天组件。

我告诉 WorkBuddy"我需要可以直接推到 Git 仓库然后一键部署的完整项目"。它随后做了一件事：去 GitHub 上把 EdgeOne Makers 的 AI-Chat-Assistant 模板仓库的完整文件结构抓取下来，然后把模板代码和我之前生成的业务配置融合到一起，产出了完整项目。

这个过程体现了一个有意思的点：WorkBuddy 不是一个"只能按预设模板生成代码"的工具。当我提出"我需要完整可部署项目"这个新需求时，它自己判断了需要去获取模板仓库，自己拆解了文件之间的依赖关系，自己完成了业务配置和模板代码的融合。我全程只给了一句话。

当然，生成的代码我逐个检查过。有些文件里的注释需要微调，有些配置项的默认值需要改成我的业务参数。但整体结构和逻辑是对的——不需要推翻重写，只需要打磨。

五、让 Agent 跑起来

项目搭建完成后，部署到 EdgeOne Makers 只需要把代码推到 Git 仓库，在平台控制台导入仓库、填好环境变量、点击部署。没过多久，Agent 就上线了。

接下来是验证。我在商家管理后台的"投诉管理"页面加了一行 embed.js 引用，右下角弹出了对话入口。我试着像运营人员一样跟它对话。

这段对话覆盖了 Agent 的核心能力链：理解意图、查询数据、读懂状态、组织回应内容、确认后执行、返回结果。运营人员全程没有离开管理后台，没有去微信后台输入投诉单号，更没有操心 AccessToken。

从运营人员的角度看，她做了三件事：问 Agent 有什么待办、看了一条详情、说了一句处理意见。其余全由 Agent 和后端自动完成。小王后来跟我说，她每天处理投诉的时间从三小时压缩到了四十分钟。

六、复盘：造物者的自省

做完这个项目，有几个点值得复盘。

关于 Agent 的定位。 一开始我差点把它做成一个"投诉知识问答机器人"——用户问投诉政策是什么，Agent 回答一段话。但那样做没有触及真正的痛点。真正的痛点是操作：查状态、填表单、提交。所以 Agent 的定位应该是"操作助手"而不是"问答机器人"。这个判断决定了后面的架构设计——Agent 必须能调用真实接口，而不只是生成文字。

关于工具 Schema 的 description。 这是我在整个项目里花时间最多的一处。每个工具的描述不能只写"这个工具做什么"，还要写"什么情况下该用它"和"什么情况下不该用它"。比如 supply_proof 的描述里明确写了"仅当投诉状态为 106 时可用"——这句话看起来多余，但如果没有它，Agent 可能在状态 201 的时候也试图调用补证接口，导致微信返回错误。description 是 Agent 判断"该不该调这个工具"的主要依据，写得越精确，Agent 的表现越稳定。

关于安全边界。 AppSecret 放在 Java 后端而不是 Agent 里，这个决定从第一天就定下来了，没有动摇过。原因不是技术上做不到——Agent 的环境变量里完全可以塞 AppSecret——而是安全原则上不应该做。Agent 的运行环境比 Java 后端更不可控，一旦泄露就是根凭证泄露。多一道代理层，多一层防线，值得这点额外复杂度。

关于 WorkBuddy 的角色。 在这个项目里，WorkBuddy 做的事情横跨研究、设计、编码、文档四个阶段。它抓取了微信文档，设计了系统提示词，生成了 Java 代码和前端组件，最后还产出了部署指南。如果我自己做这些事，至少需要三四天。WorkBuddy 把它压缩到了一个下午。

但有一点我必须说清楚：WorkBuddy 产出的是"初稿"和"骨架"，不是"成品"。每一份生成的代码和配置，我都做了 review 和调整。比如系统提示词里状态码对照表的措辞，我改了三遍才定稿——第一版太啰嗦，第二版太简略，第三版才找到了"让 Agent 一眼能理解"的平衡点。工具是加速器，不是替代品。它帮我跳过了从零到一的冷启动阶段，但从一到一百的打磨仍然需要人的判断力。

七、写在最后

这个项目让我对"AI Agent"这个词的理解变得具体了。Agent 不是一句 Prompt，不是一个聊天窗口，不是一段生成文本的代码。Agent 是一个能理解意图、能调用工具、能做出判断、能执行操作的复合体。它的价值不在于"能聊天"，而在于"能干活"。

投诉处理只是微信小程序业务中的一个切面。同样的架构可以迁移到订单查询、退款审批、售后工单、数据看板等场景——只要后端有 API，Agent 就能成为连接运营人员和业务系统的智能入口。

而 WorkBuddy 在这个过程中的角色，是"帮我把想法变成可运行代码的那个搭子"。它读文档、写代码、搭骨架、产文档，我负责做判断、定方向、把关质量。这种协作模式——人做决策，工具做执行——是我目前用过的效率最高的一种。

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海