# 企微拟人化销售回复：GitHub 开源项目源码研究

## 1. 研究结论

调研日期：2026-08-06。

实现状态：本轮已在通用包独立实现 P0 的生成前销售动作规划、可配置 Journey/动作账本、分句级未来承诺校验、同会话生成串行和 stale reply 丢弃。实现没有复制第三方受限源码，也没有引入房产业务阶段。

没有发现一个开源项目已经提供经过独立验证、可直接复制的“房产经纪人销冠话术”。企微项目主要解决消息接入、幂等、会话隔离和渠道限制；回复自然度和销售推进能力主要来自成熟客服框架的条件化规则、对话阶段、动作状态、事实约束、人工接管和多轮评测。

本项目应保留现有确定性 `qualityScore/qualityChecks` 作为最终硬门，在生成前新增“本轮唯一销售动作”规划，在发送前新增“真实动作证据、旧回复过期和虚假未来承诺”检查。通用包只实现可配置引擎；房产阶段、带看目标、学区和产权规则继续留在业务 overlay。

## 2. 重点项目

### 2.1 Parlant：条件化行为与可跳转 Journey

- 仓库：[emcie-co/parlant](https://github.com/emcie-co/parlant)
- 研究时约 18.2k stars，`develop` 最近提交日期为 2026-07-10，Apache-2.0。
- 核心证据：[Guidelines](https://github.com/emcie-co/parlant/blob/develop/docs/concepts/customization/guidelines.md)、[Journeys](https://github.com/emcie-co/parlant/blob/develop/docs/concepts/customization/journeys.md)、[message_generator.py](https://github.com/emcie-co/parlant/blob/develop/src/parlant/core/engines/alpha/message_generator.py)、[response_analysis_batch.py](https://github.com/emcie-co/parlant/blob/develop/src/parlant/core/engines/alpha/guideline_matching/generic/response_analysis_batch.py)。

值得学习：

- 把业务规则表示成 `condition -> action`，每轮只注入当前相关规则，避免所有话术长期堆在 system prompt。
- Guideline 动作完成后进入已执行状态；上下文变化时才重新激活，适合解决同义重复追问。
- Journey 是可跳过、回退、重入的状态图，不要求客户机械按问卷顺序回答。
- 生成前提取少量 actionable insights；生成结果逐项标记事实来源、遵循/违反的指令、是否重复、是否需要继续修订。
- 自然表达强调短、暖但不客套、主动推进、避免重复、只说提示中有来源的事实。

不直接照搬完整 Python 运行时或多轮 LLM guideline matcher。当前 Node 架构只需独立实现规则匹配、优先级、Journey 状态和动作账本；现有事实硬门继续保留。

### 2.2 Chatwoot Captain：生产客服质量与真实接管

- 仓库：[chatwoot/chatwoot](https://github.com/chatwoot/chatwoot)
- 研究时约 35.5k stars，`develop` 最近提交日期为 2026-08-05。
- 核心证据：[core_rules.liquid](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/lib/captain/prompts/snippets/core_rules.liquid)、[assistant.liquid](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/lib/captain/prompts/assistant.liquid)、[response_rewriter.rb](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/app/services/captain/assistant/response_rewriter.rb)、[false promise handler](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/app/jobs/captain/conversation/v1_false_promise_handler.rb)、[handoff_tool.rb](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/lib/captain/tools/handoff_tool.rb)、[ResponseBuilderJob](https://github.com/chatwoot/chatwoot/blob/develop/enterprise/app/jobs/captain/conversation/response_builder_job.rb)。

值得学习：

- 回复保持一到两句、短句和简单词；多步骤一次只给一步；不使用机械列表；不以“还有什么可以帮您”结束。
- 知识不足时最多问一个真正影响回答或路由的澄清问题；目标已明确时，不用追问掩盖能力不足。
- 单独检测“我会稍后核实、回电、通知、转交”等未来工作承诺。只有工具本轮执行成功，才允许声明动作已完成。
- 超长回复单独做 `temperature=0` 重写，强制保留姓名、数字、日期、链接、警告、已完成动作和 citation 顺序。
- 人工接管在锁内确认会话仍由机器人负责，并检查模型运行期间是否来了更新客户消息；旧回复或旧接管动作直接丢弃。
- resolved marker 分隔不同咨询 episode，避免旧问题覆盖本轮意图。

许可边界：Captain 核心位于 `enterprise/`，受 Chatwoot Enterprise License 限制。只可独立实现同类机制，不复制其生产代码或模板。

### 2.3 OpenAI CS Agents Demo：结构化状态与少问多做

- 仓库：[openai/openai-cs-agents-demo](https://github.com/openai/openai-cs-agents-demo)
- 核心证据：[airline/agents.py](https://github.com/openai/openai-cs-agents-demo/blob/main/python-backend/airline/agents.py)、[airline/context.py](https://github.com/openai/openai-cs-agents-demo/blob/main/python-backend/airline/context.py)、[airline/guardrails.py](https://github.com/openai/openai-cs-agents-demo/blob/main/python-backend/airline/guardrails.py)、[server.py](https://github.com/openai/openai-cs-agents-demo/blob/main/python-backend/server.py)。

值得学习：

- 已存在的客户字段不再询问；资料足够时同轮执行必要工具并返回结果。
- 每轮只允许一个主要 handoff，完成后总结实际变化、确认信息和下一步。
- 公开客户字段和内部状态分离；tool、handoff 和 guardrail 事件结构化审计。
- relevance/guardrail 重点审最新用户消息，减少旧历史误判。

不照搬航空业务和演示中的随机业务编号；其输出仍需经过本项目现有质量门。

### 2.4 Pipecat Flows：阶段工具与暖转人工

- 仓库：[pipecat-ai/pipecat-flows](https://github.com/pipecat-ai/pipecat-flows)
- 核心证据：[FlowManager](https://github.com/pipecat-ai/pipecat-flows/blob/main/src/pipecat_flows/manager.py)、[warm_transfer.py](https://github.com/pipecat-ai/pipecat-flows/blob/main/examples/warm_transfer.py)、[patient_intake.py](https://github.com/pipecat-ai/pipecat-flows/blob/main/examples/patient_intake.py)。

值得学习：每个阶段拥有自己的目标、工具和转移条件；工具成功后才迁移阶段；人工接管前生成客户诉求、已知事实和失败原因摘要。只迁移状态思想，不引入语音传输栈，也不做线性问卷。

### 2.5 Scenario：多轮客户模拟与逐项裁判

- 仓库：[langwatch/scenario](https://github.com/langwatch/scenario)
- 核心证据：[scenario_executor.py](https://github.com/langwatch/scenario/blob/main/python/scenario/scenario_executor.py)、[user_simulator_agent.py](https://github.com/langwatch/scenario/blob/main/python/scenario/user_simulator_agent.py)、[judge_agent.py](https://github.com/langwatch/scenario/blob/main/python/scenario/judge_agent.py)、[scenario_state.py](https://github.com/langwatch/scenario/blob/main/python/scenario/scenario_state.py)。

值得学习：用不同客户画像连续运行多轮场景；每个场景有明确成功、失败条件和最大轮次；逐项检查重复提问、工具调用和下一步推进。LLM 裁判只用于离线评测，不接入实时发送链。

### 2.6 企微通道项目

| 项目 | 主要价值 | 采用边界 |
| --- | --- | --- |
| [CowAgent](https://github.com/zhayujie/CowAgent) | 微信客服回调先 ACK、按 `open_kfid` 串行、cursor 原子持久化、冷启动不重放历史、会话并发为 1 | 通道可靠性强；没有可验证的销冠话术或完整人工接管 |
| [LangBot](https://github.com/langbot-app/LangBot) | WeCom/微信客服适配、唯一 msgid、个人目标限制、pipeline/session 隔离、限流和内容过滤测试 | 可参考协议与测试；回复策略仍依赖上层 Agent |
| [openclaw-china](https://github.com/BytePioneer-AI/openclaw-china) | cursor + msgid 双重幂等、冷启动 prime、统一 envelope、空 payload 不发送 | 仓库未发现许可证；默认开放策略不适合本项目白名单默认值 |
| [WxJava](https://github.com/binarywang/WxJava) / [go-wecom](https://github.com/wenerme/go-wecom) | 成熟企业微信 API、客服 bot/人工状态、消息去重和统计模型 | 适合作为协议参考，不提供回复质量逻辑 |

## 3. 现有能力与缺口

| 能力 | 当前状态 | 结论 |
| --- | --- | --- |
| 首句直答、最多一个问题、阶段下一步 | 已实现 | 保留 |
| 事实证据、敏感承诺、风险人工审核 | 已实现确定性门 | 保留并继续作为 hard gate |
| 一次质量重写、失败降 review | 已实现 | 保留 |
| 纯确认/致谢静默 | 已实现 | 优于 Parlant 的持续回复默认，不改 |
| 动态 `condition -> action` guideline | 已实现 | 每轮稳定选择一个 `primaryMove`，跟踪规则只在未确认时命中 |
| 可跳转 Journey 和持久阶段 | 已实现可配置引擎 | 支持跳过、回退、重入；行业阶段由项目覆盖层提供 |
| 已执行销售动作账本 | 已实现 | `planned/executed/confirmed` 显式持久化，已确认 guideline 不重复执行 |
| 虚假未来工作承诺 | 已实现 | `future_promise_evidence` 与 `performed_action_evidence` 为 hard check |
| 模型运行期间新消息到达 | 已实现 | 入站先入库、同会话串行；生成后和自动发送前校验最新 inbound |
| 会话 episode 边界 | 缺失 | 人工结束、长间隔或业务完成后建立边界 |
| 风格适配和短语重复 | 只拦完整回复重复 | 新增语气画像与短语/动作重复检查 |
| 多轮模拟评测 | 现有 48 条以单轮/固定上下文为主 | 增加多轮客户模拟，不替代人工盲评 |

## 4. “销冠感”的可执行定义

“销冠感”不等于提高 temperature、增加热情词或随机套话，应由以下可验证行为形成：

1. 记住客户说过的一个具体点，并在本轮自然引用，而不是重复完整画像。
2. 先回答当前问题或接住顾虑，再决定本轮是追问还是行动建议；两者不机械同时出现。
3. 每轮只推进一个主要目标，问题最多一个。
4. 问题优先级按“对匹配/决策的影响 × 当前未知程度 × 当前阶段相关度 ÷ 回答成本”选择。
5. 推荐时说明一个客户侧适配原因、一个可核验事实和一个待确认风险，不只报结果或分数。
6. 异议按“确认顾虑 -> 已知证据或明确未知 -> 低成本下一步”处理，不立刻反驳或重新盘问。
7. 下一步强度跟随意向：低意向给选择权，中意向给可执行小步骤，高意向才进入真实人工接管或邀约。
8. 只声明本轮真正执行成功的动作；计划、草稿和工具意图都不能说成“已经核实/已经转交”。
9. 语言跟随客户的长短、正式度和称呼，但不模仿过度口语、情绪或错别字。

## 5. 建议目标链路

```text
标准化企微入站
-> 每会话串行 + stale-message guard
-> episode / Journey 状态恢复
-> 画像事实与 applied-action ledger 更新
-> 匹配少量 active guidelines
-> 选择本轮唯一 sales move
-> 按需执行工具
-> 生成自然 response acts
-> 事实 / 重复 / future-promise / 风险质量门
-> review 或真实发送
-> 仅在工具/发送/人工接管成功后提交阶段和动作状态
```

建议内部结构：

- `Guideline`: `condition`, `action`, `stage`, `priority`, `criticality`, `track`。
- `JourneyState`: `stage`, `completedActions`, `blockedBy`, `evidenceRefs`, `candidateNextActions`。
- `ResponsePlan`: `primaryMove`, `knownFactRefs`, `askField`, `cta`, `humanAction`, `styleProfile`。
- `AppliedAction`: `actionKey`, `sourceMessageId`, `status=planned|executed|confirmed`, `evidenceRefs`。
- `StyleProfile`: `sentenceTarget`, `formality`, `addressing`, `emojiPolicy`, `verbosity`。

这些字段是内部状态，不外发固定标题。最终客户回复仍是自然的 1-3 个短句。

## 6. 实施优先级

### 已完成的 P0 实现

- `agent-sales-move-planner.js`：结构化 Guideline、六类通用动作、唯一 `primaryMove` 和规则命中审计。
- `agent-conversation-journey.js`：可跳转 Journey 与 `planned/executed/confirmed` 状态机。
- `conversation_journeys` / `conversation_applied_actions`：当前阶段和动作账本的显式 SQLite 持久化。
- `response-future-promise-verifier.js`：分句识别核实、通知、回电、交接、处理等声明；证据必须同动作、成功且作用域匹配。
- `AgentWorkbenchService`：每会话 Promise 队列、`agent_response_stale_discarded` 审计、auto/autopilot 发送前 stale guard。
- `QiweiAgentRuntime`：生成前注入本轮唯一销售动作，工具轮次后重新规划；现有确定性质量门仍为最终发送门。

可选配置为 `QIWEI_AGENT_REQUIRED_PROFILE_FIELDS`、`QIWEI_AGENT_SALES_GUIDELINES_JSON` 和 `QIWEI_AGENT_JOURNEY_JSON`。未配置行业 Journey 时使用单一通用 active 阶段，不硬编码房产流程。

### P0：可信与不乱序

- 每会话生成串行化，发送和建草稿前确认 inbound 仍是最新消息。（已完成）
- 新增虚假未来动作检查；tool/handoff 未成功时禁止“我正在查、稍后回、已经转交”。（已完成）
- 把“要求人工”与“人工已经接管”分成两个状态，Delivery 仍只认真实 outbound。
- 建立 episode boundary，防旧问题和旧 Session 原话污染本轮。

### P0：销售动作规划

- 新增动态 guideline matcher、动作优先级和 applied-action ledger。（已完成）
- `planner` 每轮只输出一个 `primaryMove`：回答、顾虑承接、补一个关键字段、给方案、处理异议、推进下一步或人工接管。
- 画像已有字段直接 hydrate，禁止换说法重问；信息足够时执行工具并回答。

### P1：拟人表达

- 将回复拆为内部 response acts，再自然渲染，不输出机械四段式。
- 增加短语级重复、模板开头、被动结尾和过度推销检测。
- 提供可配置 `responseGuidelines/guardrails/specialistPlaybook`，通用包不硬编码房产阶段。
- 渠道限长重写锁定数字、日期、专名、风险和 citation 顺序。

### P2：多轮评测

- 将现有 48 条冻结集扩展为多轮场景，覆盖跳阶段、一次提供多个字段、反悔、沉默后回流、连续异议和人工接管。
- 同时报告 hard fail、重复字段、虚假承诺、stale reply、销售动作完成率、短语重复率和人工盲评自然度。
- 只有旧版/新版同输入真实回复盲评通过后，才宣称拟人化或销售推进能力提升。

## 7. 不采用的路线

- 不整体迁入第三方 Python/Ruby Agent 运行时。
- 不复制 Chatwoot `enterprise/` 代码或提示模板。
- 不用提高 temperature 制造随机口语。
- 不用固定八阶段电话销售脚本强迫微信客户按顺序回答。
- 不把 LLM 裁判放进实时发送链。
- 不用随机话术库绕过短语重复，而是基于当前事实、阶段和唯一动作生成。

## 8. 下一阶段验收

1. 同一会话并发两条入站，旧回复和旧接管均不发送、不建当前草稿。
2. 没有成功工具/接管事件时，所有未来工作承诺均被拦截。
3. 已确认字段的同义追问为 0；Journey 可跳过已完成阶段。
4. 普通合格回复误杀率继续不高于当前门槛，人工路径不受 Agent 门阻断。
5. 多轮盲评分别报告房产业务和通用客服，不用单轮确定性夹具替代真实自然度结论。

## 9. 本轮确定性验收

- 销售动作规划：11 项检查、14 组计划，所有计划恰好一个主动作。
- Journey 状态机：25 项检查；草稿不推进，成功 send/tool/handoff 证据才可确认动作。
- 未来承诺：21 个场景、52 条断言；无关 citation/工具结果、失败工具和跨分句“待核验”均不能旁路。
- 并发链路：6 项检查；review、auto、autopilot 的旧生成结果都被丢弃，人工明确审批保持可用。
- 既有质量门：低质量拦截 11/11，合格样本误杀 0/11，A4 冻结坏回复覆盖 10/10。
- Agent/Runtime：`agent:smoke` 48/48、`runtime:smoke` 25/25。

这些是确定性工程回归，不代表真实客户自然度或销售转化率。拟人表达的真实增益仍需多轮同输入模型候选和独立盲评确认。