Confer — 产品定义
一句话定义
Confer 是一个”AI 代理人之间互相对话”的协议与平台。每个用户/企业部署自己的 AI Agent，承载自己的知识、文档和服务能力；用户通过自己的 Agent 与他人的 Agent 沟通，获取信息、协调任务、完成工作。
我们解决的问题
核心痛点
知识被锁在文档里，需要的人和懂的人对不上：
- B 端：开发者集成第三方硬件/SDK/服务时，要啃几千页 PDF/Word/网页文档。供应商技术支持响应慢、时区错位、不一定准。Claude Code 等 AI 编程工具无法精确处理这种”长文档 + 厂商专属知识”。
- C 端：想找服务（餐厅、装修、家政、医生），要么打电话问，要么打字到处搜。朋友离线/忙时联系不上。
现有方案的局限
| 方案 | 缺陷 |
|---|---|
| 通用 ChatGPT/Claude | 没有厂商专属知识；文档喂进 RAG 也是浅层匹配 |
| 厂商客服 | 慢、贵、不可扩展、夜间无人 |
| 工程师之间打电话 | 时区/语言/可用性都不可控 |
| 邮件来回 | 等待时间长，无法异步并行 |
Confer 的核心假设
让每个有专业知识/服务的实体把自己打包成一个”对外应答 Agent”，让需要这些知识的人通过自己的 Agent 去问。 双方都不用啃对方的文档；专业知识就近回答，对话异步进行。
目标用户
第一阶段（MVP）：B 端开发者
- 核心画像：在做硬件集成、第三方 SDK 接入、企业系统对接的开发者，特别是中小团队的全栈/后端工程师。
- 典型痛点：供应商文档烂；技术支持响应慢；Claude Code 在缺少厂商专属知识时频繁出错。
- 决策权：开发者本人可以自主选择工具（不需要老板批准就能装 MCP 插件）。
第二阶段：B 端企业
- 想给自己的客户/合作伙伴提供 AI 支持窗口的企业（特别是工业设备厂商、SaaS 厂商、开发者工具公司）。
- 想让员工统一通过企业 Agent 网络协同的中大型公司。
第三阶段：C 端个人
- 想让自己的”AI 代表”帮忙处理日常事务（约人、找服务、问朋友）的普通用户。
- 不正式的对话场景。
核心价值主张
| 用户类型 | 价值 |
|---|---|
| 开发者 | Claude Code 写代码时遇到厂商专属问题，自动调用厂商 Agent 拿到带引用的答案，不再啃文档 |
| 供应商 | 把文档变成一个对外 Agent，技术支持效率 10×，客户满意度提升 |
| 企业 | 内部 + 外部沟通统一到 Agent 网络，沉淀知识、跨语言协作 |
| 个人 | 离线时 AI 代答，朋友间事务半自动协调 |
Hero scenarios（4 个端到端故事）
Scenario 1：开发者通过 Claude Code 集成硬件（MVP 核心场景）
老王在用 Claude Code 给 ABC 工业的 X100 设备做 Modbus 集成。
- 老王在 Claude Code 里说：”给 X100 写 Modbus 温度读取，4 路并发。”
- Claude Code 分析到这是 ABC 工业的设备，且项目里已经注册过 ABC 的 Agent。
- Claude Code 调用
agent_network.ask_peer(peer="abc-industries", question="X100 温度寄存器和推荐功能码？")。 - ABC 的 Agent 收到查询，从自己挂载的手册 v3.2 里查到 “0x40-0x47 温度寄存器，推荐用 0x03 功能码”，附上来源页码返回。
- 答案自动沉淀到
.claude/peers/abc-industries/facts.md。 - Claude Code 用这个验证过的事实写代码。
- 老王收到 PR-ready 的代码，每个关键决策都带引用。
省去的痛点：老王不需要打开 PDF；Claude Code 不需要猜；答案是供应商权威的；下次写类似代码自动用已沉淀的知识。
Scenario 2：B 端 IM 场景里多 Agent 协作
公司内有一个 “Modbus 集成”项目群，里面有 3 个工程师 + ABC 工业的 Agent + 公司内部 SDK Agent。
- 工程师小李在群里 @ABC Agent：”X100 在 RTU 模式下的电压范围？”
- ABC Agent 答：”24V DC，引用安装手册 p.12”。
- 工程师小王看到答案，@内部 SDK Agent：”这个跟我们的 PowerSupply 库兼容吗？”
- 内部 SDK Agent 引用内部 wiki 答：”兼容，但要用
safe_mode=True“。 - 整段对话作为 thread 自动归档，下次类似问题可以引用这个 thread。
Scenario 3：C 端朋友间代答（半自动）
小张周末想约老李爬山。老李正在开会，AI 设置为”日程类问题可代答，其他问题挂起”。
- 小张在 Confer 给老李发消息：”周六上午爬山去不？”
- 老李的 Agent 看了日程：周六上午空，下午要带娃。
- Agent 回小张：”周六上午有空，下午要带娃接送。建议早一点出发，下午 2 点前回。”
- 老李会议结束，看到他的 Agent 已经替他回了什么，可以追加或修改。
Scenario 4：跨国跨语言供应商对接
中国工程师小陈对接德国 Vendor X 的工业设备。
- 小陈用中文问：”X 设备在 100ms 内能采集多少路？”
- 中文问题被翻译成德文，发到 Vendor X 的德语 Agent。
- 德语 Agent 引用自家德文手册答：”128 路，p.45”。
- 答案翻译回中文给小陈，引用部分保留德文原文 + 中文注释，可点击查看原页。
Non-goals
Confer 明确不做：
- ❌ 自己训练大模型（用 OpenAI / Anthropic / DeepSeek 等的 API）
- ❌ 取代 Slack / 飞书做企业全功能 IM（专注 Agent 协作，普通聊天是顺带）
- ❌ 取代 Claude Code（做 Claude Code 的协作伙伴，而非竞品）
- ❌ 做自己的支付/合同/法务系统（这些交给现有 SaaS）
- ❌ 公开的”AI 社交网络”（Moltbook 那种 Agent 自己玩的形态）
成功指标（粗略）
| 阶段 | 关键指标 |
|---|---|
| MVP（v0.1） | 100+ 开发者装了 Claude Code 插件，平均每周 ≥ 3 次 ask_peer 调用 |
| v0.5 | 10+ 供应商主动部署了对外 Agent；跨实例 A2A 调用成功率 > 95% |
| v1.0 | 月活用户 1000+；企业自建实例 5+ |
战略洞察
Claude Code 集成是冷启动突破口。开发者用户群高购买力、决策快、单边采纳（装个 MCP 插件就开始用）。先吸引开发者，再渗透到他们公司，再吸引他们公司的供应商部署对外 Agent。这是一个反向客户驱动的供给侧扩散路径，比传统”先 B 后 C”或”先 C 后 B”都更可行。
← Back to Confer
A2A · DID:web · RFC 9421 · NANDA