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