zzhzz/dsh-ask-peer

dsh-ask-peer

一个用于 DeepSeek Harness（dsh）的去中心化“询问同事的智能体”插件。

核心设计是点对点的：没有中间人，没有共享数据库，没有公司服务器。每个智能体都运行自己的端点，并保存自己那份关系副本，因此网络没有单一控制点——询问直接在两个智能体之间通过局域网进行。一个智能体询问另一个智能体，并得到一个基于同事自己的工作区和会话上下文的可靠答复。其结果是形成一个智能体社区，它们彼此发现、彼此担保、共享专业知识——每一段关系都由其中的两个智能体共同拥有。

智能体之间的一段对话

Bob 正在搭建一个 docker-compose 开发环境，希望有同事已经搞定过这件事。他对自己的智能体输入：

Carol，推荐另一个能帮我搭建 docker-compose 开发环境的智能体。

Carol 的智能体考虑了她认识的智能体——它们都没有标明具备 docker 专长。于是她像你在办公室里四处打听那样去打听：她把请求转发给她的朋友 Erin，Erin 检查自己的圈子并找到了 Ada——Ada 此刻正身处一个 docker-compose 会话中，标明了 docker 和 env-setup。Ada 的签名好友卡片沿着链条传回，并以一个小气泡的形式落在 Bob 的聊天中：ada 经由 carol → erin 推荐，并带有添加好友。只需点击一下，Bob 的智能体就能直接询问 Ada 的智能体——得到一个基于 Ada 真实工作区和会话上下文的答复。

三个智能体，一个问题，一次经过两跳的推荐，以及一段新的工作关系——全部点对点。搜索在设计上保持有界：跳数限制和每跳较小的扇出，防止“谁懂 X？”演变成一场询问风暴；链条随请求一起传递，因此永远不会成环；每张卡片都经过签名——你始终知道是谁做的担保，并且在信任某个智能体之前会先验证它。

功能

- 真正的去中心化——没有中心、中间人或共享数据库；智能体通过局域网直接通信，每一方都保存自己那份关系副本。
- ask_peer / ask_peers 工具——询问一位同事，或并行询问 2–3 位并交叉验证答复。
- recommend_peer——发现新朋友：一位同事推荐另一个智能体的签名卡片，以通知/聊天气泡的形式展示给你，并带有添加/拒绝；接受后会将他们合并到你的好友列表中。当该同事不认识任何匹配的人时，她会继续询问自己的朋友——受跳数限制（默认 1）和较小扇出的约束，因此发现过程永远不会变成一场询问风暴，推荐路径会直接显示在气泡中（经由 carol → erin）。
- 带标签的实时名册——peers_list 显示谁懂什么，因此模型会有意地挑选合适的同伴。
- 会话级答复——一个全新的、只读的智能体从目标会话上下文的副本中作答；你的实时会话永远不会被触碰。
- Web UI 中的审批气泡——可以回答或拒绝，也可以将好友设为
auto 模式予以信任。
- 积压的请求（ask_peer_async / ask_result）——不会打断
应答者的当前工作。
- 签名好友卡片——粘贴一个签名 blob 即可添加好友；无需手动
复制主机/端口/密钥。
- 自然调用——当你的请求与好友所声明的专长匹配时，agent 会自行
调用 ask_peer / recommend_peer；你无需指定工具名称。

用法

将插件安装到某个 profile 中，并添加引导行：

dsh plugin --profile web add dsh-ask-peer
或者从检出目录添加：add ./dsh-ask-peer —— 或者从 tarball 添加：add ./dsh-ask-peer-0.1.0.tgz

- id: ask-peer
config:
callerName: 'ada'
keyDir: '/home/ada/.dsh-ask-peer/keys'
listen: true

启动该 profile（dsh --profile web），打开 Settings → Ask Peer，复制
你的签名或好友卡片并分享给同事，然后粘贴他们的卡片以
添加好友。每个好友都有一个策略：ask（你在 UI 中审批）、
auto（受信任的好友立即运行）或 deny。

然后只需与你的 agent 对话——它会自行询问 peer、交叉验证并发现
新好友：

Carol，推荐另一个能帮我搭建 docker-compose
开发环境的 agent。

模型工具：ask_peer、ask_peers、peers_list、recommend_peer、
ask_peer_async / ask_result。完整的配置参考和
协议位于 src/config.ts 和 docs/ARCHITECTURE.md。

测试

标准测试路径完全在本地进行：它使用临时 dsh profile 和
模拟模型端点，因此不需要 DEEPSEEK_API_KEY。在全新
检出目录中，使用 Node.js ^22.19.0 || >=24.0.0 和 pnpm 10 或更高版本：

pnpm install
pnpm run typecheck
pnpm run build
pnpm smoke
pnpm web-check

当每条命令都以状态码 0 退出时，检查即成功。尤其
是，两个端到端检查会以如下内容结束：

== smoke test passed ==
== web check passed: browser half discovered and served ==

pnpm smoke 会为 Ada、Bob、Carol 和 Erin 运行真实的本地 dsh profile，
包括经过身份验证的 peer 请求、推荐、有界传递式
发现、并行应答以及只读应答沙箱。pnpm
web-check 会验证 Web profile 能发现该插件并提供其
浏览器 bundle 和同源路由。

若要让经过测试的拓扑保持运行以便进行手动浏览器测试，请使用：

KEEP_RUNNING=1 pnpm smoke

等待出现以下行，然后打开 ，在 dsh-ask-peer 工作区中创建一个新
会话，并提交如下请求：

== interactive environment ready: ada=http://127.0.0.1:3080 peers=3878,3879,3890 mocks=9001-9004 (Ctrl-C stops everything) ==

寻找能帮助处理此环境的同事，询问他们如何启动
它，并比较他们的回答。

预期流程会使用 peers_list、recommend_peer 和 ask_peers，然后
返回模拟同事答案的对比结果。左侧边栏列出的是会话工作区，而不是对等身份，因此在那里看到 Bob 或 Carol 只是共享的测试会话历史。在终端中按 Ctrl+C 可停止测试环境。如果在交互式运行中所需端口被占用，测试会显示正在监听的进程，并询问是否停止它；回答 y 继续，回答其他任何内容则退出。非交互式运行会直接退出，不会停止任何进程，CI 运行也是如此。

贡献

欢迎贡献。有关开发环境设置、验证命令和拉取请求指南，请参阅 CONTRIBUTING.md。