资料负担
把客户背景、行业判断、关键人、会前问题和产品匹配点先整理成可讨论材料，售前把时间放回方案判断。
销售助手 Agent 工作台
01项目缘起
让销售走完最后一公里
不是替销售做决定，而是把客户信号、企业知识、销售判断和下一步动作，收进同一个可以继续工作的地方
销售不缺工具，缺的是一条能走到底的路径。
关系型销售的一天，常常从一份客户背景开始：售前查资料、整理方案、追会议纪要，销售再把信息搬回 CRM。客户说过的话散在聊天、文档和个人记忆里，真正需要推进时，反而没有一个地方能接住全貌。销售本来就不愿在多个企业系统之间来回切换。数据保密又决定了这不能只是把公共聊天窗口交给销售，而要把知识、记忆、权限和确认机制放在企业自己的工作台里。
产品判断
问题不是再生成一份材料，而是让销售完成一次可追踪、可确认、可继续推进的动作。
所以这套产品的判断标准只有三条：输入不改变销售习惯，判断必须有依据，外部动作必须经过确认。
输入不改习惯从语音、文字、文件或企业 IM 开始。
判断有依据事实、缺口、风险与来源分开呈现。
动作需确认写回 CRM 或外发消息前保留销售确认。
02需求挖掘与收集
观察与判断
先观察销售怎么工作，再决定 Agent 从哪里开始
在碎片化的客户现场，销售更愿意直接说出来，而不是先学习提示词、填写字段、再组织一段完整文字。这个事实决定了产品的第一个姿势：语音优先。我们没有从按钮清单开始，而是拉着销售和售前进行多轮头脑风暴和产品推演，把一次真实客户沟通从会前、会中到会后完整走一遍。
哪些内容可以先由 Agent 接手，哪些判断必须由人完成，哪些生成物能真正进入下一步工作，都在 MVP 前被逐项讨论。所以 onboarding 不是让销售先配置系统，而是鼓励他直接说出客户、项目和当前问题。
* 在一个地方把一件事做完整，比在很多地方分别提供一个功能更重要，也更容易赢得用户的喜欢
我们先把工作分成三类：Agent 可以接手的整理与检索；需要销售协同的归属与判断；必须由销售确认的写回与外发。这个边界决定了 MVP 先解决什么，也决定了 Agent 不替谁做决定。
Agent 可以接手整理输入、召回企业知识、提取事实、生成可讨论初稿。
人机协同判断确认客户 / 项目归属，补齐缺口，判断证据是否足够。
销售必须确认修改客户信息、写回 CRM、创建外部任务或发送消息。
从四个现场问题，收敛出一条 Agent 工作流
售前被查资料、改文档、同步状态占住，Agent 先生成可讨论的初稿；客户事实散落在聊天、文件和个人记忆中，客户 / 项目空间承接长期关系；销售不愿在 IM、CRM、文档和新工具间搬运信息，企业 IM 成为触达和快速回复入口；高级销售的推进经验符合 MEDDPICC，项目总览把缺口变成下一步行动。
上下文断裂
客户层、项目层、会话层分开，系统记住的不只是一句话，还包括这句话属于谁、服务哪一单业务。
系统切换
企业 IM 负责把客户动态和待确认动作送到销售面前，销售回复后再回流到对应项目。
判断不透明
MEDDPICC 不被压成一个失真的总分，而是指出当前最薄的一维和下一条需要补齐的证据。
4 个核心业务场景，15 个 MVP 任务
调研、话术演练与真人模拟、商机复盘、方案与跟进推进。产品从 0 到 1 形成可运行的 Web 工作台。
调研（证据搜集与校验）｜话术演练（会前准备与真人模拟）｜商机复盘（MEDDPICC 缺口）｜方案与跟进（生成、任务与写回）
四个场景不是四套产品入口不同，主链相同
01输入客户信号进入
02归属绑定客户 / 项目
03判断补齐证据与风险
04资产形成可复用对象
05动作生成下一步任务
归属正确客户与项目绑定可检查、可纠错。待建立基线
结果被确认销售打开并采纳结构化结果。待建立基线
任务产生下一步行动回到项目空间继续推进。待建立基线
03产品规划
把需求收敛成可验证的 MVP。
产品规划承接前面的现场问题：先定义一条客户信号到业务动作的闭环，再拆出能被销售验证的任务，不把需求讨论误写成上线后的功能清单。
每个 MVP 任务都必须回答三个问题
谁在什么时刻触发？产出哪个可复用业务对象？哪一步需要人工确认？四个场景先共享一条主链，再按入口和任务模板扩展。
验证顺序
会议后判断项目简报信息缺口下一步任务CRM / IM 确认
MVP 产品规划闭环问题假设 → 工作流拆解 → 验证指标
把分散的客户信号收进工作台
销售不需要先整理成标准字段，可以从最顺手的入口开始；系统负责识别客户、项目和本次任务。
01
语音、文字与文件表达客户现状，上传方案、纪要和已有材料
02
实时会议与录音导入持续转写，沉淀关键人、事实和会后待办
03
企业 IM 消息把新消息带着客户与项目归属送进 Agent
把信号变成有依据的业务判断
不是直接生成一段答案，而是调用销售任务、补齐企业知识，并把事实、缺口和风险分开处理。
H
Hermes + Skill理解意图，路由调研、会议、判断或生成任务
G
GBrain + 阿里百炼读取客户 / 项目记忆，检索企业知识与证据
M
MEDDPICC 诊断指出最薄维度，以及下一轮必须补齐的证据
把判断接回销售下一步动作
结果进入项目空间成为可继续使用的业务对象，并在涉及外部系统时保留销售确认。
01
项目空间资产客户简报、会议纪要、事实、缺口、风险与依据
02
任务与盯防把信息缺口转成下一步行动，持续提醒推进
03
IM 回复与 CRM 写回销售确认后发送消息、更新客户或同步跟进记录
04产品定义与工作流
Agent 的价值不在于多会回答，而在于能不能把判断接回业务。
产品没有把销售助手做成一个“什么都能问”的聊天框，而是把从客户信号到业务动作的路径组织成一个连续工作流：销售从语音、文字、文件、会议内容或企业 IM消息开始，Agent 识别当前要推进的客户和项目，选择对应的销售任务，补齐必要的企业知识和历史上下文，产出可确认的材料或行动，再将结果沉淀回项目空间和后续跟进。
这个顺序决定了产品不是“问答框 + 一堆功能”，而是一条从客户信号到业务动作的连续工作流。Agent 负责整理、判断和建议，涉及客户信息修改、CRM 写回和外部发送的动作保留销售确认，让自动化真正服务于销售的判断和关系推进。
用户只需提供一个客户信号，系统必须交付四个可检查的结果：归属、判断、资产、动作。每个结果都能回到来源；涉及客户信息、CRM 或外部发送时，确认权留在销售。
归属这句话属于哪个客户、哪一个项目、哪一次会话。
判断当前事实、缺口、风险和依据分别是什么。
资产结果如何进入简报、文档、项目空间并继续复用。
动作下一步任务是什么，哪些动作需要销售确认。
让销售用熟悉的方式开始工作
说出客户语音优先输入
识别项目自动绑定客户 / 项目
得到结果直接进入下一步
onboarding 不要求销售先学习提示词，而是让第一次输入就产生可推进的业务结果。
销售的工作高度碎片化，因此语音从一开始就被定义为主要入口，而不是文字输入旁边的附加按钮。onboarding 阶段直接引导销售说出客户、项目和当前问题，第一次输入就应该得到一个可以继续推进的结果。
用客户和项目承接上下文
客户层企业画像、关键人物、长期关系
项目层当前商机、预算、进展、决策关系
会话层本轮指令、中间结论、待确认信息
产品把客户、联系人、项目、会话、文档和任务组织成业务空间，而不是让信息停留在聊天记录里。客户层保存长期画像，项目层记录当前商机，会话层处理本次沟通，销售切换项目时不会被上一单的资料干扰。
先解决 Agent 的响应和上下文问题
Hermes理解意图
路由 Skill
路由 Skill
Skill封装销售任务
GBrain客户 / 项目记忆
阿里百炼企业知识检索
结构化结果卡片 / 任务 / 写回
Hermes 负责编排，GBrain 负责业务记忆，阿里百炼 负责外置知识召回；模型只是链路中的一个推理组件。
早期版本出现首个有效响应过慢、工具执行失败和长时间无反馈。Langfuse Trace 与服务日志显示，agent.md 写得过细、每轮携带上下文过多，GBrain 的系统提示词拼接又进一步拖慢响应并增加工具调用不稳定性，因此将稳定规则收进 Skill，并引入阿里百炼作为外置检索服务。
把企业 IM 和 CRM 放回业务边界
企业 IM消息触达
快速回复
快速回复
Agent理解上下文
生成动作
生成动作
MCP / CRM业务工具
确认后写回
确认后写回
企业 IM 负责信息触达和快速回复，Agent 负责理解消息、绑定业务上下文和生成下一步动作；CRM 负责沉淀销售确认后的业务记录。MCP 用于访问客户、项目、任务等业务工具，不承担 IM 消息传输。
05实际落地
从一次客户信号，走到可继续使用的业务资产。
销售可以用文字、语音、文件、会议内容或企业 IM 消息开始工作，结果回到项目空间、任务和业务系统。
与销售助手对话项目空间已加载
MCP CONNECTION LAYER
把企业 IM 和 CRM 接进同一条可控工作流
在这套产品里，MCP 不是新的业务系统，而是 Agent 调用企业工具的标准连接层。企业 IM 继续承担消息触达，CRM 继续承载客户、商机和跟进记录；Agent 通过 MCP 读取必要上下文、生成待确认动作，并在销售确认后调用对应工具。
01 / 事件入口企业 IM接收客户消息、群聊提醒与销售指令，携带用户和会话身份进入工作台。
02 / 任务编排Agent + MCP Client识别客户与项目，选择业务任务，把自然语言转换为受约束的工具调用。
03 / 标准工具层MCP Server统一暴露客户查询、商机更新、任务创建和消息发送等能力，并校验参数与权限。
04 / 业务落点CRM / IM 开放接口执行已确认的写回或外发动作，把结果、失败原因和业务编号返回项目空间。
只读先行先开放客户、联系人、商机和活动记录查询，验证归属与权限。
动作待确认更新 CRM、创建任务和发送 IM 前，明确展示对象、字段与内容。
执行可恢复每次调用携带幂等标识；失败保留原因、重试入口和原始草稿。
全程可审计记录操作者、工具、参数、确认人和执行结果，回流到当前项目。
产品边界Agent 负责理解、整理和建议；MCP 负责把能力标准化并受控调用；CRM 与企业 IM 仍是最终业务事实和消息状态的来源。没有销售确认，不执行外部写入与发送。
上下文不是记忆力，是归属关系。
产品把客户、联系人、项目、会话、文档和任务组织成业务空间，而不是让信息停留在聊天记录里。销售说出一个客户或上传一份材料后，Agent 会识别其中的企业、人物、需求和项目线索，并将内容归属到对应空间；后续的会议纪要、调研结果、生成文档、待办和盯防结果都继续沉淀在同一个地方。
客户层沉淀企业画像和关键人物，项目层承载当前商机的预算、进展、需求和决策关系，会话层只保留本轮沟通的临时指令和中间结论。跨项目引用必须有明确的业务意图，资料和记忆也要绑定清晰的企业与项目归属，这样才能避免关系型销售最怕的“上下文串单”。
06项目总览
把高级销售的工作流，变成项目总览。
在每个客户 / 项目空间中展示当前简报、客户完整度、八个维度的证据和评分、信息缺口、项目风险与下一步行动。评分不是为了给商机贴标签，而是为了指出下一步应该补哪条证据。
评分只做导航，不做结论低分 → 证据 → 下一轮问题
找到最薄维度先把销售注意力带到当前最需要补齐的证据。
展开缺口证据看到来源、时间、置信度和仍未确认的事实。
生成下一轮问题把分数转成访谈问题与可执行的销售任务。
项目空间 / 总览杭州 · 某制造企业 · Q3 数字化采购
MEDDPICC 项目健康
07结果资产
让结果成为可以继续使用的业务资产。
调研、会议和文件处理不再只返回一段自然语言，而是沉淀为客户简报、已确认事实、信息缺口、项目风险、判断依据和下一步行动。事实和判断分开呈现，销售可以看到依据并决定是否采纳；需要修改客户信息、创建任务、写回 CRM 或发送外部消息时，必须经过销售确认。
结果生命周期允许修改的地方与必须留痕的地方
01 · Agent 草稿可编辑，保留来源与置信度。
02 · 销售确认确认事实、缺口与下一步行动。
03 · 项目资产进入简报、文档、任务和项目空间。
04 · 外部写回CRM / IM 执行后留下审计记录。
把一次会议整理成下一次沟通的起点
客户正在评估现有系统的替换成本，业务负责人关心交付周期，财务负责人尚未进入当前对话。
已确认事实替换窗口 · Q3
当前风险经济买单人未确认
判断依据会议纪要 · 客户原话
下一步行动补充预算决策人访谈
会议、资料和生成物形成闭环
01采集会议内容持续进入
02转写形成可检索文本
03沉淀纪要、关键人、待办
04生成画像、调研、竞品对比
项目空间 · 已更新会议纪要 · 06/18关键人 2 位
待办 3 项
待办 3 项
实时会议和录音导入共用同一条沉淀链路，输出回到客户 / 项目空间，而不是停留在一次性文本里。
长任务有暂停、恢复和重试
01 确认范围02 拆分子任务03 采集与合并04 输出结论
客户背景12 条证据已合并
竞品资料08 条证据待校验
异常任务1 项可恢复
研究任务 · 进行中当前阶段：证据合并暂停
市场调研等耗时较长的工作被设计成可暂停、可恢复、可重试的研究任务：先确认范围，再拆分子任务，分阶段采集证据，合并并校验信息，最后输出结论、依据、风险和行动建议。销售可以看到任务进行到哪一步，遇到异常时能够恢复，而不是面对长时间没有反馈的黑盒。
结果不是一句“看起来合理”的答案
事实来源 · 时间
推断置信度 · 依据
风险缺口 · 影响
行动下一步 · 确认
关键事实保留来源、时间和置信度；证据不足时，系统允许留空或给出低置信判断，而不是为了让页面看起来完整而编造结论。事实、推断、风险和行动被拆开，问题才能回到具体的上下文、业务 Skill 或数据。
工具边界决定产品可信度
企业知识阿里百炼 检索
业务记忆客户 / 项目归属
业务写回CRM 确认后执行
企业知识优先从知识库检索，客户画像、历史沟通、已确认事实和信息缺口从客户与项目记忆调取。CRM 的连接范围、权限隔离、工具可用范围和写入确认在产品层明确下来，Agent 不替销售做越权决策。
08上线观察
上线后的重点不是继续堆功能，而是确认销售有没有走完路径。
Langfuse 关注 Agent 链路、任务耗时、失败和重试；PostHog 观察真实产品行为。只有从输入走到下一步动作，才说明 Agent 在帮助销售推进，而不是只提供一次回答。
看 Agent 是否稳定
关注 TTFT、不同任务的总耗时、工具调用、失败和成本，区分问题来自资料准备、知识检索、业务工具还是模型。
看销售是否继续走
观察语音输入、客户 / 项目绑定、项目空间进入、文档打开、信息缺口补齐、任务创建和企业 IM 回复。
看结果是否可信
销售反馈“结果不准”时，继续判断知识是否过期、实体是否绑错、任务是否路由错误、事实和推断是否混在一起。
上线看板只看三类信号不要把聊天次数当成功
链路稳定首个有效响应、工具失败、恢复成功。
路径完成项目绑定、简报打开、任务创建。
结果可信采纳、纠错、来源展开和确认。
09反馈调整
一次 62 秒的等待，改变了前端反馈方式。
早期版本 TTFT 偏慢、工具执行频繁失败。结合 Langfuse Trace 和服务日志拆开看，问题不只在模型：agent.md 过细，每轮带入上下文过多；GBrain 的提示词拼接也让系统指令反复堆叠。于是把稳定规则收进 Skill，把客户 / 项目记忆与企业知识检索拆开，并引入阿里百炼作为外置检索服务。
脱敏 Trace / early build总链路 62s · 问题已拆解
意图理解识别客户、项目和当前任务
1.8s输入层正常：用户意图已识别为“会议后补齐商机判断”。
上下文拼接agent.md 规则 + GBrain 记忆
14.6s问题定位：agent.md 过细，每轮带入的规则和历史上下文过多；GBrain 同时存在系统提示词拼接。
知识检索企业资料和项目证据
8.1s调整后：稳定规则收进 Skill，企业知识由阿里百炼按任务召回，减少无效上下文。
工具执行CRM / 项目任务 / 外部动作
37.5s产品动作：增加心跳、阶段状态、异常提示、任务恢复和局部重试；写回 CRM 和外部发送仍需销售确认。
技术问题如何变成产品调整发现等待 → 定位阶段 → 给出状态 → 验证恢复
发现等待用户不知道系统是在运行还是卡住。
定位阶段把 62 秒拆成上下文、检索和工具执行。
给出状态增加心跳、进度、异常和可恢复入口。
验证恢复观察任务是否继续推进并回到项目空间。
02 / 结构化结果
P0销售说“结果看起来对，但没法继续用”
反馈自然语言回答无法直接进入下一次沟通。
定位事实、推断、风险和行动混在同一段文本中。
调整增加客户简报、信息缺口、风险和下一步行动卡片，并保留来源与置信度。
03 / 上下文归属
P0销售担心切换项目后串入上一单资料
反馈同一客户多条商机并行时，信息归属不够确定。
定位聊天记录能记住内容，但不能表达内容属于哪一个业务对象。
调整建立客户层、项目层、会话层，并在项目空间中显示当前归属和切换边界。
04 / 长任务反馈
P1调研任务等待太久，销售不知道是否还在运行
反馈长时间没有反馈时，销售无法判断是等待、失败还是卡住。
定位研究任务缺少阶段状态、异常恢复和局部重试。
调整增加阶段进度、心跳、暂停、恢复、异常提示和局部重试，任务结果回到项目空间。
10总结
从客户信号到业务动作，销售终于有了一条能走到底的路径。
语音 / 文字 / 文件进入、客户项目归属、结构化结果与任务回流已串成完整主链。
Agent 负责整理与建议，项目空间负责承接上下文，销售确认后才执行 CRM / 企业 IM 外部动作。
从现场问题、产品取舍、工作台界面到 Trace 反馈，已形成一套完整的项目说明与复盘材料。