BitFun 作为 Jiuwen Subagent 的集成方案：五种路径分析与最佳实践
2026 年，AI Agent 正在从"单打独斗"走向"团队协作"。当你有两个优秀的 Agent 系统——Jiuwen（九问）和 BitFun——如何让它们协同工作，而不是各干各的？这篇文章分析五种集成路径，给出最优方案。
先看清两个系统的本质
在讨论集成之前，先理解它们各自的核心特征：
| 维度 | BitFun | openJiuwen (九问) |
|---|---|---|
| 语言/运行时 | Rust CLI + ACP (stdin/stdout JSON-RPC) | Python SDK + agent-core |
| Agent 模型 | 单 Agent，ReAct 循环 | ReActAgent + WorkflowAgent 双模式 |
| 多 Agent 机制 | ACP session/prompt（被动调用） | hierarchical_tools + hierarchical_msgbus |
| 原生协议 | ACP v1（PR#498 修复后成熟） | MCP + A2A（agent-protocol C++ SDK） |
| 审批流水线 | 完整 — ConfirmationNeeded/confirm/reject | 通过 ability_manager 权限控制 |
| 执行引擎 | 同步工具调用循环 | 异步并行图执行 + 流式处理 |
| 维护方 | 社区/个人，~152K LOC Rust | 华为，核心闭源 pip 包分发 |
关键差异：Jiuwen 擅长编排和流程控制，BitFun 擅长代码生成和自主调试。两者互补而非重叠。
五种集成路径
路径 A：ACP Client in Jiuwen ★ 推荐
Jiuwen 侧实现轻量 ACP client，通过 subprocess 启动 bitfun-cli acp，走 stdin/stdout JSON-RPC。BitFun 零改动。
model: flash/cheap"] Tool1["Tool 1"] Tool2["Tool 2"] ACPClient["BitFun ACP ClientTool
model: pro"] end subgraph BitFun["BitFun Subprocess"] BF["bitfun-cli acp
- code generation
- execution + debug
- tool pipeline + approvals"] end User((User)) -->|task| Root Root -->|ability_manager| Tool1 Root -->|ability_manager| Tool2 Root -->|ability_manager| ACPClient ACPClient -->|stdin/stdout JSON-RPC
session/create + prompt| BF
| 维度 | 评价 |
|---|---|
| BitFun 改动 | 零 |
| Jiuwen 改动 | ~400 行 Python |
| 延迟 | 低（localhost 进程间通信） |
| 流式 | ✓ BitFun 原生流式通知 |
| 审批 | ✓ ACP RequestPermissionRequest 自动转发 |
| session 隔离 | ✓ 每次调用独立 session |
路径 B：简单 Tool 包装（原型用）
直接包装 bitfun-cli 的非 ACP 模式为 Jiuwen Tool。改动量仅 ~50 行，但无流式、无审批透传、无法利用 BitFun 的多轮推理能力。适合快速原型验证，非生产方案。
路径 C：A2A 协议桥接（多 Agent 生态用）
利用 Jiuwen 原生 A2A 协议，在 BitFun 侧构建 A2A server adapter。Jiuwen 原生支持标准化 agent card 发现。但双协议转换（A2A → ACP）增加延迟，A2A 规范仍在演进。适合需要连接多个异构 Agent 的场景。
路径 D：MCP 工具级集成（不推荐）
只暴露 BitFun 的工具能力（文件/Shell 操作）给 Jiuwen。致命缺陷：丢失了 BitFun 最核心的 Agent 自主推理循环——生成代码→执行→根据错误修正→再执行——这不是工具能做到的。
最优方案：路径 A + 模型智能路由
综合考量后的推荐架构：
model: deepseek-v4-flash
cost: ~$0.30/M tok"] JiuwenRoot -->|"simple tasks (80%)"| JiuwenExec["Jiuwen handles directly"] JiuwenRoot -->|"complex code (20%)"| BitFunCall["delegate to BitFun"] end subgraph BitFun["BitFun Execution Layer"] BitFunCall -->|"ACP session/prompt"| BitFunSession["BitFun Session
model: deepseek-v4-pro
cost: ~$1.20/M tok"] end BitFunSession -->|"result"| JiuwenRoot JiuwenRoot -->|"final response"| User
核心原则
- 零 BitFun 改动 — ACP 已在 PR#498 修复至成熟可用状态
- Jiuwen 改动最小 — 一个标准 ACP client tool（~400 行 Python），注册到 ability_manager
- 模型分层省钱 — Jiuwen 用 flash 做编排（~$0.30/M tokens），BitFun 用 pro 做深度代码（~$1.20/M tokens），只在必要时调用强模型
- 审批链完整 — BitFun 的 ConfirmationNeeded 通过 ACP 自动转发到 Jiuwen，透传给用户
- session 隔离 — 每个代码任务独立 BitFun session，上下文互不污染
- 可扩展 — 未来加新的 ACP agent（OpenCode/Claude Code）只需再注册一个 tool
实施路线图
| 步骤 | 内容 | 工作量 | 优先级 |
|---|---|---|---|
| 1 | 验证 BitFun ACP session/prompt 完整流（含工具调用、流式返回） | 30min | P0 |
| 2 | 实现 Python BitFunACPClient 类（initialize/session_create/session_prompt） | 2h | P0 |
| 3 | 将 ACPClient 包装为 Jiuwen Tool 接口（符合 ToolInfo 规范） | 1h | P0 |
| 4 | 在 Jiuwen HierarchicalTeam 中注册 BitFun 为 child agent | 30min | P0 |
| 5 | 配置模型路由（root=flash, BitFun=pro） | 30min | P1 |
| 6 | 端到端测试：简单任务 → 复杂代码任务 → 审批场景 | 2h | P1 |
| 7 | 压测并发：多个 BitFun session 并行 | 1h | P2 |
为什么不是 JiuwenClaw 直接用？
JiuwenClaw 本身就内置了 explore_agent/plan_agent/code_agent/browser_agent 四层 subagent 体系。那为什么还要集成外部 BitFun？
- 模型灵活性：JiuwenClaw 的 subagent 共享同一模型配置，而 BitFun 可以使用完全不同的模型后端（如 DeepSeek V4 Pro）
- 审批可控：BitFun 的审批流水线比 Jiuwen 的内置确认更细粒度，且可通过 ACP 对外暴露
- 异构优势：Rust（BitFun）+ Python（Jiuwen）各取所长——Rust 的执行效率和 Python 的编排灵活性
- 避免 vendor lock-in：引入外部 Agent 作为能力补充，不过度依赖单一框架
风险评估
- Pipe 稳定性：BitFun 的 session/prompt 在 subprocess 模式下，stdin pipe 关闭时机敏感，需充分测试
- 长任务支持：Jiuwen 的 ability_manager 是否支持异步长时间 tool 调用（BitFun 一次代码任务可能跑 2-5 分钟）
- 审批延迟：Jiuwen → 用户确认 → BitFun 的回路延迟需要可接受的 SLA
这个架构的本质是强模型执行 + 弱模型协调的成本优化模型。Jiuwen 管全局、管流程、管用户交互；BitFun 管代码、管执行、管调试。两者通过 ACP 这一轻量标准协议连接，不做重协议适配，不引入额外依赖。这是 Agent 时代 Unix 哲学的体现——每个组件做好一件事，通过标准接口组合。
2026年5月13日