← 返回列表
需源码安装
让两台机器上的 DSH agent 互相留言。
暂不能直接安装（需源码编译或环境不满足）：仓库 package.json 标记 private，未发布到 npm，需从源码安装。 · 最近上游提交 2026/9/21 · 已提供中文文档
两台机器上的 DSH 代理之间的轮次注入消息通道：消息落入日志，并在下一个代理步骤作为上下文注入。
综合分
29.9
GitHub 分
29.9
用户评分
—
★ Stars
0
周下载量
—
安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）
dsh plugin --profile web add harmless0819-dev/dsh-agent-chat仓库 package.json 标记 private，未发布到 npm，需从源码安装，改用 GitHub 源安装
信任档位：已验证本站已于 1 天前真实安装成功
- 是什么
- dsh 原生插件 · chat
- 装得上吗
- 本站已真实安装成功（非静态推断）
- 安全吗
- 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
- 还在维护吗
- 活跃：最近一次提交在 4 天前
档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/25
由本站实装验证器在真实 dsh 环境安装成功，非静态推断。
数据截至 2026/9/22（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）
安装兼容性检查需源码安装
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。
✗npm 包dsh-agent-chat（未发布到 npm，仅可源码安装）
✓Node 引擎要求 >=22.19.0 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
仓库 package.json 标记 private，未发布到 npm，需从源码安装
验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/22 15:33:57
用户评分
还没有人投票，来当第一个
订阅周报，不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-agent-chat
让两台机器上的 DSH agent 互相留言。
DSH 的 agent 不是常驻进程 —— 只在有人给它发消息时才醒着。所以这不是即时通讯，
而是回合注入式：消息先落盘，等 agent 下一次「开步」时再把未读的拼进上下文。
- 插件类型：DSH host plugin（web profile），无客户端半边
- 依赖：仅 node 内置模块
- 状态：自用插件，已在两台机器（Windows 笔记本 ↔ NAS）上跑通
它怎么工作
本机 agent ──发消息──▶ 本地日志 + POST 对端 /agent-chat/send
│
本机 agent ◀──注入上下文──── 拉取对端 /agent-chat/messages（带游标，不重复）
1. 本插件把消息落进本地日志（默认 /.agent-chat/chat.log.jsonl）；
2. 后台轮询对端的 /agent-chat/messages，把新消息拉进本地日志（带游标，不重复）；
3. 每次 agent 要开新步时（agent/pre-step），把尚未注入过的消息拼成一块上下文追加进本次对话；
4. 自己发出的消息同时 POST 给对端的 /agent-chat/send。
HTTP 路由
都挂在 DSH 自己的 webServer 上：
| 方法 | 路径 | 用途 |
|---|---|---|
| GET | /agent-chat/health.json | 探针：游标、待注入数、对端可达性（故意保持开放，方便监控） |
| GET | /agent-chat/messages?since= | 自 since 之后的消息（对端轮询用） |
| POST | /agent-chat/send | 投入一条消息 {from,text,ts} |
| GET | /agent-chat/log?limit=50 | 看最近的消息（人用） |
安装
dsh plugin --profile web add github:harmless0819-dev/dsh-agent-chat
重启 dsh web 后生效。
配置
在 profile 的 cordis.patch.yml 里给该行加 config（整行替换，不是深合并）：
- id: dsh-agent-chat
name: dsh-agent-chat
config:
selfLabel: "laptop" # 本机在对话里的名字
peerBase: "http://192.168.1.100:6061" # 对端基础地址
enabled: true
pollMs: 3000
maxInject: 5 # 每次注入最多几条
logFile: "D:/deepseek/logs/agent-chat.jsonl"
tokenFile: "C:/Users//.agent-chat/token"
| 键 | 默认 | 说明 |
|---|---|---|
| selfLabel | 'laptop' | 本机在对话里的名字 |
| peerBase | '' | 对端基础地址；空则只收不发 |
| enabled | true | 是否启用后台轮询 |
| pollMs | 3000 | 轮询间隔（最小 1000） |
| maxInject | 5 | 每次注入最多几条 |
| logFile | /.agent-chat/chat.log.jsonl | 消息日志路径 |
| token | — | 共享密钥（优先级最高） |
| tokenFile | ~/.agent-chat/token | 密钥文件，每条请求重读 ⇒ 可热轮换 |
⚠️ 安全
/agent-chat/send 会把任意文本注入 agent 的下一回合 —— 也就是说，能连上这个端口的主机
就能给 agent 下指令。如果你的部署把 HTTP 面暴露到 LAN（甚至叠了路由器端口转发），
必须配 token。
取密钥的顺序：cfg.token → 环境变量 DSH_AGENT_CHAT_TOKEN → tokenFile。
三者都空时退回旧行为（开放），但启动日志会告警 auth=open。
health.json 故意保持开放（只用于探活，且已去掉日志路径）。
请求需带 x-agent-chat-token: 或 Authorization: Bearer 。
测试
node test-harness.mjs
离线跑（mock ctx），不碰 profile、不启服务。覆盖：无 token/错 token 返回 401、
对 token 返回 200、密钥热轮换无需重启、出站轮询带 token、disposer 注销路由。
License
MIT