三个 AI 智能体打通客服到修复交付

客服收到一句「是不是多收了钱」，往往要经过转述、补资料、复现、修复和审批，最后还可能没人通知客户。作者做的 Support-to-Ship Bridge，用 Switch 把三个 AI Agent 放进客服和工程聊天室，让它们接力处理问题，人负责批准合并和发送回复。

这个案例值得看的是它怎样把业务规则、回归测试、代码审查和执行权限串起来。不过，它展示的是一个预埋缺陷的小型演示，距离真实团队的稳定流水线，还有几道需要验证的关口。

三个 Agent 怎样把客服工单接到代码修复

Switch 是开源基础设施，可以把 AI Agent 接进 Slack、Teams、Discord、Telegram 或 Mattermost。Agent 以房间成员的身份参与工作，通过 @mention 接收任务和交接。

这里的房间比普通频道多了一层上下文：房间说明、文档、角色，以及通向其他房间的链接。大白话解释，就是把「这个群处理什么、按什么规则处理、交给谁」写成 Agent 能读取的配置。

作者设置了两个房间和三个 Agent：

• shoplite-support 在客服房间接收工单，核对定价政策，复现问题，再向工程房间升级。
• shoplite-fixer 建分支、补回归测试、修改代码，并提交给审查者。
• shoplite-reviewer 对照政策检查差异，通过后交给工程师批准合并；合并完成，客服 Agent 再准备回复，等待客服批准发送。

演示产品是一个很小的结账定价服务，提前放了两个缺陷：税费在优惠券抵扣前计算，以及免运费要求金额高于 $50，而政策要求达到 $50 即可。初始测试全部通过，因为根本没覆盖这两条规则。

工单 T-1042 提供了具体证据：客户给一件 $120 的夹克使用 SAVE20，却支付了 $8.70 税费。按政策，折后金额是 $96，税率为 7.25%，应收税 $6.96，总价 $102.96；实际总价是 $104.70，多收 $1.74。

修复 Agent 先写出失败的测试，确认 8.7 与 6.96 的差异，再用一行修改修复问题，最终 7/7 测试通过。审查 Agent 还主动发现了免运费的第二处缺陷，但原文没有展示它也被修复。

初始测试全绿，只能证明已有断言通过，不能证明业务规则完整。

作者称视频是一次真实、无脚本运行。这能说明流程确实跑通过，却不能证明它面对不同工单时都同样可靠。

为什么业务规则和失败测试要走在修复前面

三个 Agent 共用 ~/switch-demo/shoplite 下的一个 Git 仓库。初始化脚本复制演示应用并运行 git init，再次执行会重置演示状态。共享目录让修复者的分支可以直接交给审查者检查，也减少了传递补丁的步骤。

作者给修复 Agent 的指令很具体：从 main 执行 git checkout -b fix/<ticket id>，先写表达政策要求的失败测试，用 node --test 展示失败，再对 src/ 做最小修改，重新运行测试。提交后，交接信息必须包含分支、根因、差异统计和测试摘要；没有实际运行过的结果不能报告。

这套顺序有用，是因为「客户觉得多收费」还不是可执行需求。必须先把它转成「优惠后金额乘以税率」这样的明确规则，再把规则变成断言。失败测试证明当前实现违背了规则，修复后的通过结果才有解释力。

房间配置也服务于同一个目的。作者用 version: 1 的 YAML 模板，通过 bridge 参数连接聊天桥接，默认值为 [$first]；模板一次建立两个房间、升级链接、文档和角色。升级清单要求带上工单编号、客户原话、复现命令、实际与预期结果，以及对应政策条款。

模板还声明了非独占的 reviewer 和独占的 merge-captain 角色。不过，声明角色不等于已经落实审批权限，作者后面仍把按角色限制审批者列为后续方向。

启动消息 kickoff 同样有实际作用：Agent 只有被消息明确提及时才开始工作。导入模板后执行 Use → Create all，启动消息负责第一次唤醒它们，后续交接继续使用 @mention。

两次人工审批，怎样成为真正的执行关口

把「合并前先问我」写进提示词，无法替代执行层的权限检查。

作者在工作区配置 Claude Code 权限文件，让合并和发送脚本必须申请批准，同时禁止推送和硬重置：

{
  "permissions": {
    "ask":  ["Bash(git merge:*)", "Bash(node scripts/send-reply.js:*)"],
    "deny": ["Bash(git push:*)", "Bash(git reset --hard:*)"]
  }
}

重点是 ask 中两条命令：Agent 真正执行 git merge 或 node scripts/send-reply.js 时，才会触发权限请求。deny 则限制 git push 和 git reset --hard。

Switch 会把请求显示为 Permission needed · request A1，提供 Allow once、Allow for this session 和 Decline，也支持直接回复 yes 或 no，并记录批准者。演示中，作者分别点击两次 Allow once，批准合并和发送包含 $1.74 退款金额的回复。

这里要区分「准备回复」与「实际发送」。发送脚本受权限控制，人工点击才成为最后的发送动作。但原文没有展示真实支付系统的退款执行，不能把回复中的退款金额理解成资金已经退回。

跑通环境也有几个具体前提。作者使用 Docker Desktop 启动捆绑的 Mattermost，安装 Switch Console，并通过 claude、/login 登录 Claude Code。启动本地服务后，还必须在 Home → Messaging apps → Mattermost → Link → This is me 关联账号，否则 Agent 不会响应消息。Console 只在启动时读取一次 PATH，中途安装 CLI 后需要重开。

模型还必须能稳定调用工具。Switch Agent 通过 post_message 发言，最终文本不会直接显示。作者最初通过 OpenRouter 使用一个免费模型，遇到 The model's tool call could not be parsed.；换成 Claude 模型后恢复。这个结果说明该组合发生过兼容问题，不能推导成所有免费模型都不适用。

Windows 上，Switch Console 0.40.1 的模板创建 Agent 页面显示 Not supported here，但从 Your Agents → + 手动创建可以成功。作者因此采用手动建 Agent、模板只建房间的方式。每个 Mattermost 房间约需 15 秒，Console 即使提示超时，后台也可能已创建成功，重试前应先检查 Your Rooms。

若用 WSL 作为远程 Agent 主机，还要在 .wslconfig 设置 networkingMode=mirrored，让它访问仅监听 127.0.0.1 的本地服务；非交互 SSH 的 PATH 也必须能找到当前 Node.js 和 claude，不能假定包含 ~/.local/bin。

我的判断

我认可这个案例把业务依据、验证证据和执行权限放在同一条交接链上。相比直接把客户原话贴给编码 Agent，它要求先复现、再写失败测试，工程师批准时至少有具体材料可查。

但「三个 Agent 加两次审批」是不是更高效，原文没有对照数据。作者没有比较单 Agent、普通工单系统或人工处理的耗时，也没有提供成功率、模型成本和多工单并发结果。因此，减少等待是合理目标，效率提升幅度仍是经验判断。

两个前提尤其影响迁移。第一，演示的定价政策明确，真实工单可能涉及合同、历史活动和特殊约定，复现正确也可能依据了错误政策。第二，共享 Git 工作区方便演示，但多个任务同时切分支、修改文件时怎样避免互相干扰，原文没说清。

权限方案也有边界。两次 Allow once 展示了有效的执行关口，但界面同时允许 Allow for this session，实际审批粒度取决于人的选择。作者计划增加「仅 merge-captain 或指定工程师可批准合并」，说明审批者资格还需要继续收紧。

能拿来做什么

• 给 Node 定价或结算逻辑补测试时，可以沿用「政策条款、复现输入、实际结果、预期结果」四项材料，优先覆盖优惠顺序、税费和金额边界。
• 在日常 AI 修复流程中，要求 Agent 先运行失败回归测试，再提交最小修改，并附上实际执行的测试结果，让人工审查有据可查。
• 将合并与对外发送放进执行工具的权限配置，检查批准的是单次操作还是整个会话，并确认谁有资格批准。
• 试用 Switch 时，先用一张工单验证账号关联、post_message、测试运行和审批线程。Zendesk、Intercom 接入与每日待回复巡检，在原文中仍是后续方向。