anker-go · 基于 AI Native 自我迭代的客服 Agent

Anker 首届黑客松挑战赛季军 · 智能服务赛道参赛作品

认识 anker-go，你的智能硬件售后伙伴。 anker-go 是面向 eufy 智能硬件的客服 Agent（智能体），以扫地机器人排障为主要场景，结合客户描述、设备照片、知识库和订单信息，理解问题、引导分步排查、准备处理方案，并将需要审核的事项连同上下文交给人工。

anker-go 采用 AI Native 自我迭代的开发方式：由编码智能体参与分析、修复与独立测评，在人的业务判断和验收下，把失败案例持续转化为能力改进与回归测试。客服能力与开发过程共同围绕真实问题演进，具体做法见迭代闭环。

评测结果 · 架构设计 · 关键技术方案 · 技术选型 · 痛点与难点 · AI Native 迭代 · 演示案例 · 快速启动

在线体验：客户演示 · 人工工作台与管理后台

评测结果与边界

意图识别匹配率 98.4%，流程分支通过率 87.3%，单案例处理中位耗时 7.9 秒。 以下指标统一来自 2026-10-13 · 修复后第二轮（after2） 的完整 63 单评测，反映该版本、该运行条件下的实测效果。

测评集由主办方的 63 封脱敏工单构建，标注意图、业务终点、知识依据与禁止行为。该轮在重建后的服务上通过真实模型和 WeKnora 跑完整链路；驱动按固定策略推进卡片，遇到事实问题即停止，不编造客户凭证。该集合同时用于开发和评测，未作为独立留出测试集；工单不进入检索知识库。

来源：after2 完整报告、实验与修复说明。百分数按案例数计算到一位小数，复算及定义见指标核验。

流程通过率不等于回答正确率或真实解决率。 该轮仍有 T52 方案适用性错误，以及 T20、T39、T41、T43 在不同轮次中追问或发卡的波动；T57 的合理追问也可能因驱动停止而被判为未到标注终点。需结合逐案语义复核和重复运行判断效果。这组历史实测不作为当前版本保证，也不用于推算整体回答准确率或独立托管率。

当前项目用于比赛演示与工程探索。订单及办理链路使用赛题／演示数据，尚未接入真实商业订单与退款履约系统。图片细节归属、个别事实理解及重复运行稳定性仍有改进空间；多语言输入的理解与检索已纳入设计，目前客户回复主要采用英文。历史评测结论与修复状态见难点记录，需结合记录日期与代码版本阅读。

架构设计

anker-go 按接入、编排、能力、数据四层组织。模型承担理解、读图和候选方案判断，服务端代码管理流程状态与操作权限。客户发来新信息或改变诉求时，anker-go 依据已保存的状态继续处理。

图取自决赛路演 PPT 第 5 页，点击可查看原图。节点数、模型任务数与知识条目数对应路演时版本，当前配置以仓库代码为准。

一轮请求如何流转。 解析邮件或表单后，模型提取诉求与事实，服务端核对原话；故障请求进入产品确认、读图、检索与排障，物流请求可直接查询订单。需要客户补充时保存待答状态，收到反馈后继续。前端通过服务器发送事件（SSE）接收流式更新，通过 REST 接口提交消息和卡片动作。

部署采用 Docker Compose，单一编排镜像同源托管客户前端与管理前端，Redis 作为 WeKnora 的配套依赖。前后端事件、动作和快照由 Pydantic 模型定义，再生成 JSON Schema 与 TypeScript 类型。模型路由见 config/models.yaml，完整设计过程见技术设计文档，实现记录见实现进度。

关键技术方案

1. 事实账本与方案适用性

事实账本是带来源的结构化记录，保存对象、肯定或否定、客户原句和已做过的检查。它解决的是模型理解结果在后续步骤中被当成无条件事实的问题。

例如，客户说“左边能用”时，系统需要保留“左侧、能工作、原话”，再追问故障在哪一侧；客户说“只收到配件”，订单却显示整机已送达时，两种来源分别保留。选方案时，模型判断条目的适用前提，服务端核对引用是否存在，冲突或缺失的事实进入追问或人工核实。

2. 多路检索与按物体读图

检索增强生成（RAG）指先检索资料，再依据检索结果生成回答。本项目的难点是客户表达、官方条目和照片观察可能指向不同对象，语义相近并不代表方案适用。

1. 限定产品范围：按已确认型号检索；型号与错误码精确匹配，未收录的错误码不套用相近编号。
2. 补齐语言差异：客户原文与英文现象描述分别进行关键词和向量混合检索，再用倒数排名融合（RRF，按结果名次合并）汇总候选。
3. 补充图片证据：先做画质检查和方向校正，再按主体、其他物体、灯和外观异常记录；故障观察补充检索，单据进入凭证识别。静态照片无法证明闪烁等动态现象，需要追问。
4. 核对适用条件：选方案前核对条目前提与原文引用，避免把“充电盒充不进电”带到“泵无法充电”的排障步骤。

检索数量、上下文预算和可选重排等开关见 config/retrieval.yaml。

3. 状态驱动的卡片与多诉求接续

一段官方答案可能混合事实问题、操作和材料请求。如果统一展示成“解决了／没解决”，用户的回答就无法表达真实含义。

系统按内容类型生成选项卡、步骤卡、说明和上传卡，并保存“当前在等什么回答”。按钮与文字回答绑定待答状态，客户反馈决定下一步；多项诉求分别记录，查询物流或补充资料后继续未完成事项。LangGraph 保存流程状态，前端展示实际发生的节点与事件，人工接手时沿用案件上下文。

4. 独立审查与提交权限

授权闸门是服务端执行写操作前的统一检查点。主流程形成了候选方案，还需要验证该方案确实符合客户意愿和办理条件。

例如，客户在确认前将“换货”改成“退款”，旧方案不能继续提交。审查模型独立读取客户原话与订单记录，不读取主流程的方案结论；服务端再将审查结果与候选方案对照。闸门检查办理资格、材料及客户确认、安全限制、重复执行状态和独立审查结果，通过后才允许提交服务单，存在差异则交人工核实。

相关实现：独立审查、提交闸门。

5. 事务边界与重复提交控制

幂等指同一个请求重复提交时复用处理结果。一次会话包含模型调用、数据库写入和服务单调用，无法用一个数据库事务覆盖全部步骤。例如建单成功但响应丢失，直接重试就可能重复办理。

这些保证有明确边界：同一订单跨会话去重、建单后多步写入与对账仍有缺口，详见事务与一致性设计。

技术选型

模型配置见 config/models.yaml，组件版本见下文版本锁定。Redis 是 WeKnora 的配套依赖，业务会话锁由 PostgreSQL 实现。

痛点与难点

售后问题往往带着情绪、信息缺口和多个诉求一起出现。客户可能已经清理、重启过设备，同时还想查另一笔订单；客服既要理解这些上下文，也要知道什么时候继续排查、什么时候交给人工。

这要求系统同时处理语言理解的不确定性和业务操作的确定性：事实要有来源，多项诉求要有状态，操作要有授权，结果要有回执。项目将这些约束分别落实到事实记录、会话状态图、提交检查和执行记录中。

项目参加了 Anker 首届黑客松挑战赛的智能服务赛道，并获得季军。赛题背景见智能服务赛道说明。

五个售后难点

项目围绕主办方提供的 63 封脱敏客诉工单开发与评测，涉及英、荷、法、德、西五种语言，以及故障照片、购买凭证和 App 表单。难点不仅在于找到答案，还在于读准客户说的对象、条件和处理意愿。

这些机制用于约束错误和保留证据，仍有图片细节归属、事实理解与重复运行稳定性等已知问题，见评测结果与边界。

AI Native 自我迭代

AI Native 在 anker-go 中指两层实践：产品中由模型理解非结构化输入、判断候选方案；开发中由编码智能体参与分析、实现和评测，持续把失败案例转成可验证的改进。迭代对象包括事实抽取、检索、知识、流程和交互，先依据证据定位问题所在层，再决定改动。

开发与测评由不同 Agent 分工，业务边界由人确定。 项目使用 Claude Code、Codex 等编码智能体分别承担取证修复与独立测评；人负责确定业务口径、变更范围和最终验收。一次迭代保留输入、运行版本、过程证据、改动与复测结果，使下一轮可以继续核对。

例如 T27“已清理仍堵塞”：测评发现系统没有承接已做检查，取证定位到表单解析只取了首行、漏掉后续描述。修复扩展到下一个字段之前的完整内容，并补齐已做检查的事实记录；10 月 13 日独立复测三次均保留这些信息。见修复方案与独立复测结论。同轮复测仍发现 T30 的读图错误、T61 的选路波动，所以局部断言通过后，还要检查整体语义和稳定性。

当前已实践的是人参与、证据驱动的工程迭代闭环。下一步计划将经审核的服务案例沉淀为知识与回归样本，串起候选版本评测、受控发布和效果观察，见服务质量与知识迭代设计。自动训练、自动修改线上代码与无审核发布尚不属于已实现能力。

演示案例

E28 路演案例将上述设计串在一次对话中：客户同时提出设备换货和配件物流诉求，anker-go 分别记录并查询物流；补齐机器订单和序列号后准备换货方案，客户随后改为退款，anker-go 更新方案、等待确认并检查提交条件，最后展示服务单回执与人工接续状态。

截图采集于 2026-10-17，展示线上路演版本，界面与演示数据可能领先于当前主分支。案例使用虚构订单和 AI 生成的示例附件；服务单提交表示等待后续处理，不代表已退款或发出替换设备。

组成

快速启动

前置：Git、Docker 24+ 与 Compose v2。首次构建会下载镜像和依赖。

git clone https://github.com/xiaokekehaha/anker-haike.git
cd anker-haike
cp .env.example .env        # 按模板填写模型、数据库和知识库配置
make up                     # 构建并拉起 orchestrator / postgres / redis / weknora-app / weknora-docreader
make health                 # 查看聚合健康

模型与图片理解需要配置相应厂商凭据，默认路由见 config/models.yaml；嵌入与重排配置见 .env.example。首次使用还需完成业务库迁移与知识库初始化：本机安装 Python 3.12、uv 并执行 make dev-sync 后，使用 make db-upgrade、make kb-bootstrap、make kb-ingest 和 make kb-verify，可通过 make help 查看说明。知识库导入命令会替换旧演示知识库，应使用本项目独立环境。

停止：make down（保留数据）。重置全部数据：make reset。首次拉起 WeKnora 镜像与 docreader 约需数分钟。

本机闲置时暂停项目、关闭 Colima，以及下次恢复 PostgreSQL / Redis / 前后端的完整步骤，见 本机服务暂停与恢复。只停止本项目；其他项目使用同一 Docker 实例时保留该实例运行。

本机开发

应用进程可直接运行在本机；完整会话与知识检索仍依赖 PostgreSQL、Redis 和 WeKnora。后端需要 Python 3.12 与 uv，前端需要符合 package.json 要求的 Node.js。

make dev-sync               # uv 安装后端依赖
make dev-api                # 起编排服务，读根目录 .env

另一个终端启动前端：

npm --prefix frontend ci
npm --prefix frontend run dev

访问 http://localhost:5173，开发代理连接本机 8000 端口。更多说明见前端开发文档。组件状态可通过 /health 查看；依赖未就绪时不代表完整业务链路可用。

常用检查：make lint、npm --prefix frontend run typecheck；完整 CI 复现使用 make ci-local。所有命令见 make help。

版本锁定

数据库运维

迁移（Alembic）、每日备份、一键恢复与单点风险说明见 docs/runbook/database.md。常用：make db-upgrade、make db-backup、make db-backup-status、make db-restore FILE=…。

发布与回滚见发布手册。问题反馈可提交 GitHub Issue，请附复现步骤、预期行为与脱敏后的实际结果。