38 KiB
dsh-im 产品价值与演进分析
状态：产品价值分析，不代表已经决定实施具体功能
初始日期：2026-08-26
更新日期：2026-08-29
讨论来源：Issue #58、Issue #63、Issue #65
关联文档：机器人消息来源元数据注入方案、风险说明
说明：本文最初从 Issue #58 出发，现结合 Issue #63 与 Issue #65，对 dsh-im 的整体产品价值与演进方向进行梳理。
1. 结论
Issue #58 与 Issue #65 分别提出了两个表面上很小、实际上会改变 dsh-im 产品定位的问题：
Issue #58：用户发来消息时，Agent 能否理解谁在什么场景说话？
Issue #65：用户没有先发消息时，宿主任务能否在需要时找到用户？
前者补充了理解用户与场景的能力，后者补充了主动触达与结果交付的能力。它们组合后暴露出一个比“方便接入 Harness”更大的产品价值：
dsh-im 可以成为 DeepSeek Harness 面向真实用户世界的交互层。
dsh-im 的价值正在从单一的渠道连接能力，扩展为四类相互加强的长期资产：
| 资产 | 核心问题 | 产品价值 |
|---|---|---|
| 入口 | 用户通过哪个渠道和机器人来到 Agent？ | 把机器人变成部门、品牌、业务线或服务的 AI 入口 |
| 场景 | 谁在说话，当前是私聊、群聊还是其他交互环境？ | 让 Agent 理解用户所处的真实沟通场景 |
| 触达 | 任务完成或业务事件发生后，如何回到正确的用户？ | 让 Agent 从被动应答走向异步工作和主动服务 |
| 闭环 | 结果送达后，用户如何确认、追问、审批并继续流程？ | 将一次回答变成持续的 Agent—用户交互关系 |
Issue #58 表面上是把以下五个字段提供给处理消息的 AI：
channel
conversationType
senderId
senderName
botId
如果只把它理解为“在用户提示词前增加一段 JSON”，功能本身并不大；它真正有价值的方向是：
为 dsh-im 建立一层统一的、按机器人配置的消息上下文。
再结合 Issue #65 所启发的主动触达价值，dsh-im 的产品定位可以概括为：
原定位：让机器人更方便地接入 DeepSeek Harness
↓
当前更准确的定位：面向 DeepSeek Harness 的多渠道 Agent 交互网关
↓
长期方向：连接用户沟通场景与 Agent 能力的交互基础设施
这不是否定“接入插件”的价值，而是从它向上扩展一层：多渠道连接仍是基础和产品入口，但 dsh-im 长期不只解决“消息如何送到 Harness”，还可以解决“用户如何在真实沟通场景中使用 Agent”和“Agent 如何在需要时重新找到用户”。
这层上下文位于平台原始事件和 Harness 用户消息之间，把模型原本看不到的渠道、会话和参与者信息转换成九渠道统一语义：
平台原始事件
→ dsh-im 归一化消息来源
→ 当前机器人的上下文使用策略
→ 当前用户消息
→ Harness Session
→ 处理该消息的 Agent/模型
这层上下文让当前 Session 背后的 AI 获得此前缺失的场景感知：谁在说话、通过哪个入口说、当前是私聊还是群聊。
两个 Issue 还共同揭示了 dsh-im 的价值会产生复利：
每增加一个渠道，所有 Agent 交互能力都多一个用户入口；
每增加一种交互能力，所有已接入渠道都可能获得新价值；
每增加一个业务机器人，就多一个部门、品牌或业务线入口；
每接入一种宿主任务或业务事件，就多一种主动服务用户的方式。
因此，dsh-im 的含金量不再只来自“已经接入九个渠道”，而来自它正在积累一套跨渠道的用户入口、场景理解、主动触达、结果交付和交互闭环。无论具体 Issue 最终是否实施，这些讨论都帮助项目更清楚地看到了自身作为 Agent 与用户之间“最后一公里”交互层的价值。
2. 本文所称的 Agent
本文的 Agent 不是飞书、微信、Slack 等渠道机器人，也不是 dsh-im 或 Harness Session 本身，而是：
当前 Harness Session 背后，负责消费用户消息、调用模型和工具并生成结果的 AI 执行体。
概念关系为：
IM 用户
→ 渠道机器人：平台消息入口
→ dsh-im：渠道适配与消息装配
→ Harness Session：会话历史与执行状态
→ Agent：处理消息的 AI 执行体
→ 模型：Agent 用于理解和生成内容的组成部分
Agent Preset 决定一个新 Session 的 Agent 如何被组装，包括 persona、系统提示词段、工具和 Skills；消息来源上下文描述的是当前这一轮消息的外部场景，两者不是同一个概念。
3. 当前最直接的用户价值
3.1 群聊中区分当前发言人
这是五个字段在当前产品中最明确的价值。
群聊中的多位成员共享一个 Session 时，Agent 可以看到连续的消息，却未必知道每条消息由谁发送。例如：
张三：我下周一休假。
李四：我周二也休假。
当每条消息携带独立的 senderId 和可用的 senderName 后，Agent 有机会把两项陈述分别归属到张三和李四，而不是把两次“我”理解为同一个人。
由此可以改善：
- 群聊问答中的称呼和回应对象；
- 会议或讨论总结中的观点归属；
- 行动项、承诺和待办的成员归属；
- 同名成员之外的稳定参与者区分；
- 后续追问时对前序发言人的引用。
这主要改善的是共享群聊会话内的说话人识别。
3.2 区分私聊和群聊语境
同一段文字在私聊和群聊中可能具有不同含义：
- 私聊中的“帮我总结一下”通常面向当前用户。
- 群聊中的“帮我总结一下”通常面向整个讨论。
- 私聊适合针对个人连续追问。
- 群聊需要避免把某位成员的意见表述成全体共识。
- 群聊回复可能需要明确称呼当前发言人。
conversationType 为 Agent 提供了理解这种语境差异的基础。
3.3 感知渠道使用场景
channel 可以帮助 Agent理解用户当前所处的交流环境，例如移动端即时通信、团队协作工具或社区频道。
潜在用途包括：
- 在移动端渠道中倾向于简洁回答；
- 在协作渠道中倾向于任务列表和结构化总结；
- 在群组或社区渠道中采用适合公开讨论的表达；
- 在生成操作说明时考虑用户当前是否方便阅读长内容。
渠道格式渲染仍然应该由 dsh-im 负责；channel 的价值是场景提示，不是让模型直接处理平台 API 或消息协议。
3.4 识别机器人入口
botId 可以标记消息通过哪个机器人进入。当前每个机器人已经独立保存 Workspace、Agent Preset 和 Session 映射，因此它对“防止上下文混淆”的直接帮助较弱。
它的中长期价值在于表示业务入口：
售前机器人
售后机器人
HR 机器人
项目管理机器人
社区机器人
不同品牌或租户的机器人
但是原始 botId 只是一段内部标识。没有额外的业务映射时，模型无法从 feishu_xxx 推导它属于 HR、销售还是售后。若未来需要业务入口感知，还需要显式的 botRole、businessLine 或服务器端映射。
4. 五个字段的价值分布
| 字段 | 当前直接价值 | 中长期价值 | 局限 |
|---|---|---|---|
channel |
提供渠道场景 | 渠道运营、内容策略和来源分析 | 不应让模型处理平台协议 |
conversationType |
区分私聊和群聊 | 交互策略和工作流入口 | 只提供事实，不自动产生行为 |
senderId |
稳定区分群聊参与者 | 统一用户身份、长期记忆、CRM/员工映射 | 不能直接作为可信身份或权限凭据 |
senderName |
自然称呼和发言归属 | 人物视图、会议总结展示 | 可变、可缺失，不适合做稳定键 |
botId |
标记机器人入口 | 部门、品牌、租户和业务线入口 | 没有业务映射时语义较弱 |
当前版本中，conversationType、senderId 和 senderName 对群聊体验的价值最直接；channel 提供通用场景；botId 更偏向未来的业务入口模型。
5. 从“来源数据”到“上下文使用策略”
只把原始 JSON 写进用户消息，只能保证模型看见数据，不能说明模型应该如何使用。因此讨论进一步发现了第二层能力：
来源数据
→ 告诉模型当前发生了什么
上下文使用策略
→ 告诉模型希望怎样理解和使用这些事实
当前功能方案把“上下文增强”设计为机器人卡片上的设置入口。点击后打开弹窗，群聊与私聊各自设置三个维度：
- 是否在当前场景使用：群聊和私聊两个独立开关，默认均关闭。
- 为当前场景提供哪些来源事实：每个场景都可从五个字段中选择，默认只选
senderId。 - 当前场景如何使用这些事实：群聊与私聊各有一份增强提示词，默认留空，可分别查看说明、填入示例或清空。
群聊与私聊不共用字段选择或提示词正文。例如群聊提示词可以是：
有 senderId 时用它区分发言人；
有 senderName 时可用于称呼和观点归属；
不要在普通回复中展示 senderId 和 botId。
私聊可以另行配置更轻松或更详细的表达策略。用户只编辑各场景的增强提示词正文；非空时，<dsh_im_source_guidance> 和 </dsh_im_source_guidance> 由 dsh-im 自动添加。清空并保存某一场景后，该场景不再附加提示词块，也不会自动填入示例；另一场景不受影响。
以当前会话已开启、五个字段全选且均可用、正文非空为例，dsh-im 最终发送：
<dsh_im_source>
{"channel":"telegram","conversationType":"group","senderId":"123456","senderName":"张三","botId":"telegram_xxx"}
</dsh_im_source>
<dsh_im_source_guidance>
有 senderId 时用它区分发言人；
有 senderName 时可用于称呼和观点归属；
不要在普通回复中展示 senderId 和 botId。
</dsh_im_source_guidance>
用户原始消息
这使同一个 Agent Preset 可以被多个机器人复用，而各机器人通过自己的上下文策略表达不同入口的交流方式。
这项扩展已经超出原 Issue“传递五个字段”的最小范围。若实施，应该明确区分：
- 来源字段语义和真实值由 dsh-im 维护；用户可以选择发送哪些字段，不能手工改写来源事实；
- 增强提示词按机器人、按群聊/私聊场景分别保存正文，非空时由插件添加外围标签；首次未配置时保持为空，可选择填入对应示例；
- 群聊、私聊分别保存启用开关和来源字段；当前会话类型关闭时，两个增强块都不附加；
- 所选字段无可用值时省略来源块，提示词为空时省略提示词块；两者都为空则保持原消息；
- 使用说明属于用户提示词增强，不是系统提示词，也不是完整 Agent Preset；
- 接收消息时只读取其真实会话类型对应的字段和提示词，不允许另一场景的配置串入。
这让“上下文增强”从一次性的数据附加，进一步成为用户可以明确配置的上下文策略：哪些场景需要增强、提供哪些信息，以及希望模型怎样使用，三者各有独立的选择空间。
6. 它填补了现有产品中的一层空白
当前产品主要有两层配置：
Agent Preset
→ 新 Session 的长期角色、提示词、工具和 Skills
用户消息
→ 每一轮的临时任务输入
消息来源能力可以补充中间两层：
Agent Preset
→ Agent 的基础能力和长期角色
机器人上下文策略
→ 这个入口希望如何理解渠道、会话和参与者
消息来源上下文
→ 当前这一轮是谁、在哪里发言
用户正文
→ 用户实际提出的问题
这一中间层的特点是：
- 按机器人独立配置；
- 不要求创建专用 Agent Preset；
- 不修改 Harness 协议；
- 可以在下一条消息立即生效；
- 九个渠道使用相同字段语义；
- 能与现有和未来的任意 Preset 组合。
从产品定位看，这比“增加五个字段”更接近一层轻量的机器人上下文策略。
7. dsh-im 的产品定位升级
7.1 从渠道连接器到 Agent 交互网关
dsh-im 原来解决的核心问题是：
如何让飞书、企业微信、钉钉、Slack 等渠道机器人更方便地接入 DeepSeek Harness？
在这一定位下，dsh-im 的主要价值是：
- 适配不同平台的事件和回复协议；
- 把聊天映射到 Harness Session；
- 将消息送入 Harness；
- 把 Harness 运行结果返回原渠道。
这个定位仍然成立，但它只描述了技术连接关系。Issue #58 提出了一个更深的问题：
当消息已经能够送达 Harness 之后，Agent 是否知道这条消息是谁、在什么场景、通过哪个业务入口发出的？
一旦 dsh-im 开始回答这个问题，它就不再只是搬运消息的通道，而是开始承担以下职责：
平台事件
→ 提取真实交互场景
→ 归一化为 Agent 可消费的上下文
→ 按机器人的交互策略组装消息
→ 将 Agent 的结果以渠道原生方式交付给用户
因此，更准确的当前定位可以表达为：
dsh-im 是面向 DeepSeek Harness 的多渠道 Agent 交互网关。
长期愿景则可以表达为：
dsh-im 是连接用户沟通场景与 Agent 能力的交互基础设施。
“插件”是 dsh-im 与 Harness 集成的技术形态，不应被用来限制其产品价值。它不需要替代 Harness，也能成为 Harness 与真实用户之间的关键交互层。
7.2 天然接近用户带来的四类稀缺资产
dsh-im 位于用户和 Agent 之间，比单纯的模型或工具编排层更接近真实使用现场。这使项目天然积累四类资产。
入口资产
dsh-im 知道用户通过哪个渠道、哪个机器人来到 Agent：
渠道
→ 机器人
→ 部门、品牌、业务线或服务阶段
→ 对应的 Agent 能力
用户往往不会先进入一个通用 AI 界面再选择 Agent，而是直接在已有沟通工具中找到 HR、售后、销售或项目机器人。这个机器人就是业务入口。
场景资产
dsh-im 是最容易获得真实交互环境的一层：
- 当前是私聊还是群聊；
- 当前发言人是谁；
- 消息是否处于线程、回复或 @ 关系中；
- 用户是在手机即时通信、团队协作还是社区频道中；
- 用户与机器人此前完成了哪些交互。
这些信息不是模型可以仅从一段消息正文中可靠推断的，却会直接影响 Agent 如何理解和回应用户。
主动触达与结果交付资产
dsh-im 还有机会成为 Harness Agent、定时任务和业务事件重新找到用户的通道：
时间到了
任务完成了
业务状态变化了
风险或异常出现了
Agent 需要人类决策了
↓
dsh-im 把信息交付给用户所在的沟通场景
这项资产让用户不必停留在浏览器、Harness 或某个长任务页面中等待。用户可以把工作委托给 Agent，离开当前界面，再在结果准备好或需要参与时自然地回到流程中。
主动触达的核心价值不是“机器人会发一条通知”，而是：
Agent 的工作不再必须与用户当前是否在线、是否停留在任务界面绑定。
交互闭环资产
dsh-im 不只能把一句话送进模型，也不只是把一个结果推给用户，还有机会承载完整的交互循环：
用户需求或外部事件
→ Agent 理解、执行或等待条件
→ dsh-im 主动交付进度、结果或决策请求
→ 用户查看、追问、确认、选择或审批
→ Agent 根据用户反馈继续工作
→ 最终以渠道原生形式完成交付
真正的 Agent 产品并不只是“问一句、答一句”。追问、确认、授权、进度、中断、重试和结果交付都发生在交互层。主动消息也不是一次单向推送的终点，而可以是下一轮交互的起点。这是 dsh-im 相对于普通 API 连接器和通知服务更有长期价值的部分。
7.3 Issue #58 为什么是一个转折点
五个字段并不足以单独支撑一个庞大的产品故事。它们的重要性在于，它们是 dsh-im 第一次显式地尝试将“平台事件”翻译成“Agent 交互上下文”。
只做协议转换：
平台消息 → 用户正文 → Harness
开始理解交互场景：
平台消息 → 统一上下文 + 用户正文 → Harness
前者的核心指标是“能否接入更多渠道”；后者还需要关心：
- Agent 是否获得了正确的场景事实；
- 不同渠道的语义是否统一；
- 机器人是否能表达自己的业务入口和交互策略；
- Agent 结果是否以符合当前渠道的方式交付；
- 一次任务是否能在消息场景中形成完整闭环。
因此，Issue #58 的直接开发量可以很小，但它带来的认知变化很大：
dsh-im 的中心问题可以从“如何接入 Harness”，扩展为“如何让用户在所在的沟通场景中有效地使用 Harness Agent”。
7.4 Issue #65 为什么又是一个转折点
Issue #63 最初提出“任务完成后通过 IM 渠道发送通知”，用户显式关注某个 Session 可以解决其中一类场景。Issue #65 进一步提出的是更通用的产品命题：不仅是用户显式关注的 Harness Session，定时任务、看板、长任务和其他宿主能力是否也能借助 dsh-im 触达用户。
它把 dsh-im 的产品关系从：
用户先发来一条消息
→ dsh-im 把消息送给 Harness
→ dsh-im 对原消息进行回复
扩展为：
任务、时间或业务事件发生
→ 结果或决策请求需要找到人
→ dsh-im 把它交付到用户所在的 IM 场景
→ 用户可以直接反馈并继续流程
因此，Issue #65 的最大价值不是“可以定时发一条消息”，而是它首次明确了：
dsh-im 可以是整个 Harness 宿主中的统一用户触达与结果交付层。
这使 dsh-im 从被动问答机器人，走向可以支撑异步 Agent、事件驱动工作流和持续用户服务的交互基础设施。
7.5 Issue #58 与 Issue #65 共同形成一进一出
两个 Issue 的价值不是彼此独立的：
Issue #58：理解用户
用户 → 渠道和场景上下文 → dsh-im → Harness Agent
Issue #65：重新找到用户
Harness Agent / 定时任务 / 业务事件 → dsh-im → 用户
用户收到结果后继续回复
→ 又进入带有场景上下文的新一轮交互
当输入上下文、Agent 执行、主动交付和用户反馈能够首尾相接时，dsh-im 才真正从“接入通道”进入“交互闭环”。
7.6 与 Harness 和业务系统的边界
定位升级不意味着 dsh-im 要把所有 Agent 能力都实现一遍。更有长期稳定性的分层是：
用户与沟通场景
↓
dsh-im
多渠道接入、交互上下文、业务入口、会话路由、结果交付
↓
DeepSeek Harness
Agent 运行、模型调用、工具编排、Session 状态
↓
业务服务
可信身份、权限校验、数据访问、事务执行、审计
dsh-im 应该深挖的是“离用户近”才能做好的能力，而不是无限扩张边界。特别是：
- 不替代 Harness 运行和编排 Agent；
- 不把提示词中的来源字段当作身份认证；
- 不让模型决定用户的实际权限；
- 不在 dsh-im 中保存数据库用户名和密码；
- 不把通用数据库访问、业务事务和审计都变成插件职责。
边界越清晰，dsh-im 作为交互网关的价值反而越突出。
7.7 定位升级对产品建设的启发
如果认可这一定位，未来的产品建设重心也会发生变化：
| 原来更关心 | 未来还需要关心 |
|---|---|
| 接入了多少渠道 | 不同渠道的交互语义是否统一 |
| 消息能否收发 | Agent 是否拿到理解场景所需的上下文 |
| 机器人的连接配置 | 机器人的业务入口、Agent 能力和交互策略 |
| 文本问答是否成功 | 追问、确认、进度和结果交付是否形成闭环 |
| 用户发来消息后如何回复 | 任务、时间和业务事件如何在需要时找到用户 |
| 回答是否成功返回 | 用户收到结果后是否能参与决策并推动任务继续 |
| 对 Harness 接口的适配 | 对用户在真实场景中使用 Agent 的整体体验 |
机器人卡片也可能逐步从“连接参数表单”变成“Agent 业务入口配置”，除了渠道凭据之外，还能显式表达：
- 这个机器人面向谁；
- 它代表哪个部门、品牌或业务线；
- 它使用哪个 Agent Preset；
- 它向 Agent 提供哪些交互上下文；
- 它希望 Agent 如何处理群聊、私聊和渠道差异；
- 它在哪些场景中承载主动触达和异步结果交付；
- 它如何向用户展示进度和交付结果。
这些都可以从 Issue #58 所开始的“消息来源上下文”和 Issue #65 所开始的“宿主主动触达”向外渐进演化，但不必一次全部实现。
8. dsh-im 的价值层次与复利效应
8.1 第一层：连接效率
dsh-im 最初的价值是用一个插件统一管理多种 IM 渠道，让机器人更方便地接入 DeepSeek Harness。
这层价值降低了渠道接入、凭据管理、会话映射和结果回传的重复成本。它是 dsh-im 的基础，也是后续所有价值能够跨渠道复用的前提。
8.2 第二层：用户交互价值
当 dsh-im 开始理解渠道、机器人、发言人、私聊、群聊、回复和线程时，它提供的就不只是连接，而是一个比通用 AI 界面更贴近用户现场的交互环境。
这层价值解决的是：
- 用户不需要离开已有沟通工具；
- Agent 不再只看到一段失去场景的文字；
- 不同机器人可以承载不同的业务入口和交互策略；
- Agent 的进度、问题、审批和结果可以以符合渠道的方式呈现。
8.3 第三层：异步 Agent 与主动服务价值
主动触达让 Agent 工作与用户当前是否在线解耦。用户可以委托长时间任务、离开界面，在结果完成、条件满足、状态变化或需要人类决策时被自然地唤回。
它的价值可以逐层深化：
通知：把一条信息送达用户
→ 异步交付：把 Agent 的长任务结果送回用户
→ 事件驱动交互：业务事件发生后请求用户行动
→ 持续服务：Agent 长期关注目标，在合适时机主动回到用户身边
从“用户使用 Agent”到“Agent 持续服务用户”，是 Issue #65 所打开的最大想象空间。
8.4 第四层：生态公共能力价值
如果每个定时任务、看板、业务插件或 Agent 都要分别理解每个 IM 渠道，业务能力与渠道之间会形成乘法关系：
没有统一交互层：
业务能力数 × 渠道数 = 持续增长的重复建设
通过 dsh-im：
业务能力 → dsh-im → 多渠道用户
一旦 dsh-im 成为统一交互层：
- 新渠道可以为已有业务能力新增用户入口；
- 新交互能力可以被已有渠道共同复用；
- 新宿主能力可以借助已有机器人找到用户；
- 业务方不需要把交互、渠道和 Agent 编排混成同一套实现。
这使 dsh-im 从一个功能插件逐步具备平台型价值。
8.5 含金量来自不可轻易替代的交互资产
dsh-im 的含金量不应只由代码量、渠道数或功能数量衡量。真正逐渐难以替代的是：
- 对不同渠道真实交互语义和能力边界的长期理解；
- 把九种平台事件转换成统一 Agent 上下文的能力；
- 机器人、业务入口、会话场景与 Agent 能力之间的关系；
- 让进度、追问、审批、产物和结果在渠道中原生呈现的用户体验；
- 让任务和业务事件能够找到正确用户并继续交互的触达关系；
- 在模型概率性与身份、权限、事务确定性之间建立的清晰边界。
当这些资产形成后，替代 dsh-im 就不再只是重新调用几个渠道 API，而是需要重新建设一套用户入口、场景语义、主动触达、原生交付和交互闭环。
9. 未来业务想象力
9.1 群聊中的团队协作 Agent
来源上下文可以让 Agent 有机会理解群内人物和发言归属：
- 谁提出了需求；
- 谁承诺了任务；
- 谁表达了不同意见；
- 谁需要补充材料；
- 会议结束后每个人分别有哪些行动项。
未来可以从普通问答机器人演进为群聊中的讨论整理者和协作助手。
当结合主动触达时，它还可以在会议后追踪行动项，在截止时间前提醒相关成员，在信息不足时重新回到群里请求补充，从“整理讨论”走向“推动协作完成”。
9.2 多渠道客户服务与销售入口
企业可以在微信、企业微信、WhatsApp、Telegram、Slack 等渠道部署不同机器人：
- 来源上下文帮助 Agent理解当前渠道和客户入口；
senderId可以成为后续统一客户身份映射的原始键；botId可以映射品牌、地区、产品线或服务阶段；- 同一套 Agent 能力可以服务多个渠道入口；
- 客户状态变化、工单更新或应跟进时，Agent 可以回到客户原本所在的沟通场景。
长期演进路径可以是：
渠道身份
→ 统一客户身份
→ 客户资料和业务状态
→ 受限的业务工具与工作流
9.3 企业内部员工服务
当渠道身份能够映射企业身份后，可以形成：
- 员工在飞书或企业微信中查询个人信息；
- 群聊中把任务和行动项关联到成员；
- 私聊中继续处理员工此前提出的问题；
- 根据部门和角色进入不同业务服务；
- 审批到达、截止时间临近或员工需要补充资料时，通过日常 IM 主动触达。
来源字段本身不等于可信企业身份，但它是建立身份映射所需的入口信息。
9.4 多机器人业务矩阵
未来一个 dsh-im 实例可能管理一组业务机器人：
渠道
└─ 机器人
└─ 业务角色
└─ Agent Preset
└─ 工具和业务服务
例如：
| 机器人 | 业务定位 | 可能使用的能力 |
|---|---|---|
| HR 机器人 | 员工服务入口 | 假期、招聘、员工资料工具 |
| 销售机器人 | 客户与商机入口 | CRM、合同、报价工具 |
| 售后机器人 | 服务入口 | 工单、订单、设备工具 |
| 社区机器人 | 社区运营入口 | FAQ、内容检索、反馈收集 |
在这个模型中：
Bot = 业务入口
Agent Preset = 能力组合
消息来源上下文 = 当前参与者与交流场景
主动触达 = 任务、时间或业务事件找到用户
业务工具 = 确定性操作
权限服务 = 实际授权边界
9.5 异步 Agent 与事件驱动服务
过去的聊天机器人默认用户在线等待，而很多高价值 Agent 任务天然是异步的：
- 深度研究、数据分析和代码开发；
- 长时间巡检、监控和等待条件；
- 多步骤工作流与外部系统处理；
- 需要在中途等待用户确认或审批的任务；
- 长期关注某个目标，条件满足后再行动的任务。
如果 Agent 完成工作后无法回到用户身边，它的异步能力就很难转化为完整的用户价值。主动触达让用户可以真正把工作委托给 Agent，而不是一直陪着 Agent 工作。
主动消息又可以自然地成为新一轮交互的起点。例如，“报告已生成”只是通知，而“报告已生成，是否现在发送给客户？”会把用户直接带入下一个决策节点。
这使 dsh-im 可以支撑从“问答”到“委托”、从“通知”到“事件驱动交互”的产品跃迁。
9.6 dsh-im 作为上下文与交互中间层
dsh-im 当前的核心职责是连接九个 IM 渠道与 Harness。来源上下文能力揭示了一个更广的产品方向：
不仅传递消息，还把平台世界中的上下文翻译成 Agent 可以消费的统一语义，并把 Agent 的进度、结果和交互请求送回用户所在的场景。
未来可扩展的上下文包括：
threadId
replyTo
mentionedUsers
groupName
messageLanguage
botRole
businessLine
tenantId
clientCapabilities
这些字段不应无边界地全部塞入提示词，但它们展示了统一上下文模型的演进空间。与之对应，主动触达也不应被只理解为“主动发文本”，而应被理解为将进度、产物、决策请求和后续交互送回正确用户场景的交付语义。
10. 模型理解、主动触达与确定性处理的边界
来源信息通过用户提示词传递时，dsh-im 和 Harness 只能保证：
dsh-im：正确提取并写入来源数据
Harness：把消息保存进 Session 并提供给模型
模型：有机会理解和使用，但没有确定性保证
因此，价值必须按使用场景区分：
| 使用场景 | 是否适合依赖模型理解 |
|---|---|
| 使用昵称称呼当前用户 | 适合，失败影响较小 |
| 调整私聊或群聊表达方式 | 适合作为体验增强 |
| 群聊总结中的发言归属 | 可以辅助，重要结果应允许校对 |
| 判断用户权限 | 不适合，必须由代码处理 |
| 选择数据库租户或扩大数据范围 | 不适合，必须由服务端处理 |
| Session 隔离与消息路由 | 不适合，必须继续由 dsh-im/Harness 代码处理 |
主动触达也有同样的边界。其价值是让一个已有合理关系的任务、事件或服务在合适时机找到用户，而不是让模型可以凭提示词自行决定向任意用户发送任意消息。
模型可以帮助生成表达和理解反馈
谁有权发起触达
触达哪个用户或会话
是否符合用户预期
是否需要同意、限频和审计
→ 必须是可信业务关系和确定性规则
否则，“主动服务”很容易退化为“主动打扰”，反而会伤害 dsh-im 最重要的用户信任资产。
即使使用 Agent Preset 或系统提示词，也只能提高模型遵守规则的概率，不能形成权限保证。
如果未来需要确定性业务能力，正确分层应是：
来源上下文
→ 帮助模型理解和表达
dsh-im/身份服务
→ 解析可信机器人和用户身份
Agent Preset
→ 决定 Session 的工具集合
业务工具/API
→ 校验权限并执行确定性操作
11. 可能的产品演进
从整体产品视角看，dsh-im 的演进路径可以概括为：
多渠道连接器
→ 场景感知的消息上下文网关
→ 可主动触达用户的结果交付层
→ 渠道原生的 Agent 交互闭环
→ 企业或个人的 AI 业务入口
以下阶段不是一次性承诺，也不代表必须按顺序实施，而是用于说明每一层新价值是如何在上一层基础上生长的。
阶段一：多渠道 Agent 入口
用户可以在已有 IM 中使用 Harness Agent，不需要为每个渠道重复建设一套对话入口。
核心价值是：让 Harness 触手可及。
阶段二：场景感知的上下文网关
dsh-im 不再只搬运消息正文，而开始向 Agent 表达谁、在哪里、通过哪个入口和处于什么交互关系。Issue #58 是这一阶段的一个最小价值切片。
核心价值是：让 Agent 理解用户所在的真实场景。
阶段三：异步结果交付与主动触达
任务完成、条件满足、业务状态变化或需要人类决策时，dsh-im 可以让已有用户关系中的服务重新回到用户身边。Issue #65 是这一阶段的一个最小价值切片。
核心价值是：让用户可以真正把工作委托给 Agent，而不是一直在线等待。
阶段四：事件驱动的 Agent 交互闭环
主动送达的信息可以成为新一轮交互的起点。用户能够确认、追问、审批或修改，Agent 则根据反馈继续执行，直到完成结果交付。
核心价值是：从单轮问答走向持续完成任务的人机协作。
阶段五：企业或个人的 AI 业务入口
机器人逐步承载部门、品牌、业务线或长期个人服务的身份；Agent Preset 承载能力组合；业务服务承载可信身份、权限、数据和事务。
核心价值是：让 Agent 不只是通用对话能力，而是成为用户进入真实业务和持续服务的入口。
前三个阶段主要深挖 dsh-im 天然接近用户的价值；后两个阶段需要 Harness 和业务基础设施共同参与，不能被简化为某个提示词字段或一次主动发送。
12. 即使不实施仍然成立的启发
这次讨论至少确认了以下领域认知：
- 渠道机器人不是 Agent。 它是平台入口和消息收发主体。
- Bot 可以成为业务身份。 一个机器人可能代表部门、品牌、租户或业务线。
- Agent Preset 是能力组合。 它决定新 Session 的提示词、工具和 Skills，不是当前消息的来源信息。
- 来源上下文描述事实。 它回答谁、在哪里、通过哪个入口发言。
- 上下文使用策略描述期望行为。 它告诉模型希望怎样理解来源事实，但仍然是概率性的提示词行为。
- 权限必须由代码实施。 Agent 不能依据提示词中的元数据自行授予数据库或业务权限。
- dsh-im 可以承担语义翻译。 插件不仅能转发消息，也能把九个平台的异构事件转换成统一 Agent 上下文。
- 插件是技术形态，不是产品上限。 dsh-im 可以不修改、不替代 Harness，同时成为 Harness 面向真实用户的关键交互层。
- 入口、场景、触达和闭环是 dsh-im 的长期资产。 这些能力来自项目天然接近用户，也是单纯模型层或工具编排层不容易替代的价值。
- 更大的定位仍然需要清晰边界。 dsh-im 负责交互和上下文，Harness 负责 Agent 运行和工具编排，业务服务负责身份、权限、数据和事务。
- 主动消息不是交互的终点。 它可以唤回用户，承接用户的追问、确认或审批，然后让 Agent 继续工作。
- 异步 Agent 需要结果交付层。 如果完成后无法回到用户身边，Agent 的长任务、监控和等待能力就难以形成完整用户价值。
- 交互能力与渠道能力会相互放大。 新渠道为所有已有能力增加入口，新能力又可以通过已有渠道贴近用户。
- 用户信任是主动触达的前提。 只有在与用户预期一致、时机合理且对用户真正有价值时，主动触达才是服务而不是打扰。
这些认知可以独立指导未来的群聊、引用消息、线程、异步任务、主动触达、业务机器人、身份映射和工具授权设计，因此不依赖任何一个 Issue 是否立即进入开发。
13. 价值落地时必须保持的判断
首先必须区分当前价值切片和长期产品方向：
| 讨论 | 当前可验证价值 | 它所启发的长期方向 |
|---|---|---|
| Issue #58 | 群聊发言人归属和私聊/群聊场景感知 | 统一消息上下文与机器人交互策略 |
| Issue #65 | 定时任务、长任务和宿主事件能够交付结果 | 异步 Agent、主动服务与事件驱动交互闭环 |
长期想象力说明了方向为什么值得重视，但不能反过来替任何一个当前方案自动证明价值。每个价值切片仍应单独回答：
- 它是否让用户更容易找到 Agent，或让 Agent 更容易回到用户身边；
- 它是否让 Agent 对用户场景的理解更准确；
- 它是否缩短了“Agent 产生结果”到“用户收到并采取行动”之间的距离；
- 它是否能跨多个渠道和业务入口形成可复用的交互语义；
- 它是否带来用户可感知的闭环，而不只是增加内部能力；
- 它是否尊重用户预期和信任，避免将主动服务变成主动打扰；
- 它是否保持了 dsh-im、Harness 和业务服务的职责边界。
同时，以下表述仍然不应被夸大：
- 提示词元数据不是可信身份、权限或租户路由；
- 主动触达不意味着模型可以任意联系用户；
- dsh-im 成为交互网关，不意味着它要替代 Harness 或业务系统；
- 五个来源字段和一次主动送达都只是价值入口，不是完整产品终态。
14. 总结
Issue #58 与 Issue #65 的直接价值切片都可以很小，但它们共同暴露出的产品方向很大：
不只是把 IM 机器人接入 Harness，
而是开始定义 Agent 如何进入用户所在的真实沟通场景。
它们分别补上了 Agent 用户交互的两个关键方向：
Issue #58：让 Agent 理解用户与场景
Issue #65：让任务与 Agent 在需要时重新找到用户
它们组合后，dsh-im 开始具备一套完整的长期价值链：
用户通过渠道和业务机器人进入
→ dsh-im 提供场景上下文
→ Harness Agent 理解、执行和等待
→ dsh-im 在合适时机交付进度、结果或决策请求
→ 用户回复、确认、审批或追问
→ Agent 继续工作并完成闭环
因此，dsh-im 的含金量不是来自功能简单堆叠，而是来自一组会相互放大的资产：
多渠道 × 业务入口 × 场景上下文 × 主动触达 × 交互闭环
Harness 更理解 Agent 如何运行，业务服务更理解身份、权限、数据和事务，而 dsh-im 可以专注于一个同样稀缺的问题：
用户如何在自己所在的沟通场景中遇见 Agent、被 Agent 理解、收到 Agent 的工作结果，并与 Agent 持续完成事情。
这也是 dsh-im 更准确的产品定位：
从多渠道接入插件，走向连接用户沟通场景与 Harness Agent 能力的交互网关。