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

1. 研究结论

调研日期：2026-08-06。

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

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

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

2. 重点项目

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

仓库：emcie-co/parlant
研究时约 18.2k stars，develop 最近提交日期为 2026-07-10，Apache-2.0。
核心证据：Guidelines、Journeys、message_generator.py、response_analysis_batch.py。

值得学习：

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

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

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

仓库：chatwoot/chatwoot
研究时约 35.5k stars，develop 最近提交日期为 2026-08-05。
核心证据：core_rules.liquid、assistant.liquid、response_rewriter.rb、false promise handler、handoff_tool.rb、ResponseBuilderJob。

值得学习：

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

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

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

仓库：openai/openai-cs-agents-demo
核心证据：airline/agents.py、airline/context.py、airline/guardrails.py、server.py。

值得学习：

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

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

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

仓库：pipecat-ai/pipecat-flows
核心证据：FlowManager、warm_transfer.py、patient_intake.py。

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

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

仓库：langwatch/scenario
核心证据：scenario_executor.py、user_simulator_agent.py、judge_agent.py、scenario_state.py。

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

2.6 企微通道项目

项目	主要价值	采用边界
CowAgent	微信客服回调先 ACK、按 `open_kfid` 串行、cursor 原子持久化、冷启动不重放历史、会话并发为 1	通道可靠性强；没有可验证的销冠话术或完整人工接管
LangBot	WeCom/微信客服适配、唯一 msgid、个人目标限制、pipeline/session 隔离、限流和内容过滤测试	可参考协议与测试；回复策略仍依赖上层 Agent
openclaw-china	cursor + msgid 双重幂等、冷启动 prime、统一 envelope、空 payload 不发送	仓库未发现许可证；默认开放策略不适合本项目白名单默认值
WxJava / 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、增加热情词或随机套话，应由以下可验证行为形成：

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

5. 建议目标链路

标准化企微入站
-> 每会话串行 + 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. 下一阶段验收

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

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。

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

qiwei-humanlike-sales-reply-github-study.md 16 KB История Исходник

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

1. 研究结论

2. 重点项目

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

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

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

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

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

2.6 企微通道项目

3. 现有能力与缺口

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

5. 建议目标链路

6. 实施优先级

已完成的 P0 实现

P0：可信与不乱序

P0：销售动作规划

P1：拟人表达

P2：多轮评测

7. 不采用的路线

8. 下一阶段验收

9. 本轮确定性验收

qiwei-humanlike-sales-reply-github-study.md 16 KB

История Исходник