fuli-context 0.9.0 → 0.10.0

package/docs/roundtable-beta-testing.md

@@ -1,102 +0,0 @@
-# Agent 圆桌 Beta：跨电脑测试
-
-Beta 是独立发布通道。它不会自动升级你的稳定版 Fuli、修改其他 Agent 的全局配置，或复制长期知识到公共房间。
-
-## 安装与协调端
-
-要求 Node.js >=24.12。
-
-```powershell
-npm install -g fuli-context@beta
-fl --version
-fl roundtable serve --port 3738
-```
-
-打开 `http://127.0.0.1:3738/roundtables`。创建目标，选择讨论或协作任务，设置席位及上限。没有 Fuli 项目时创建独立临时任务作用域；关联既有 Fuli 项目必须使用准确的项目 ID，并通过现有 Provider 验证。
-
-每个席位生成独立邀请，秘密仅显示一次。不要把邀请保存到公开仓库、长期知识或发言中。席位加入后开始圆桌。房间、消息、尝试、任务、结果保存在用户数据目录的 `roundtables.sqlite`；停止服务不会删除记录。中断的尝试等待用户恢复，不静默重做可能已有副作用的工作。
-
-## 其他电脑上的 Agent
-
-协调端需要一个你控制的 HTTPS 地址。可使用已有反向代理或 Tailscale HTTPS 服务；只公开 `/roundtable-peer/`，保持控制台在本机。配置 `--public-url` 让协调端接受准确的代理 Host：
-
-```powershell
-fl roundtable serve --port 3738 --public-url https://roundtable.example
-```
-
-参与电脑分别使用自己的邀请和已登录的客户端：
-
-```powershell
-$env:FULI_ROUNDTABLE_TOKEN = '从本机控制台复制的席位邀请'
-fl roundtable worker --url https://roundtable.example --room ROOM_ID --runtime codex --workspace C:\work\project
-# 另一电脑用另一邀请：
-fl roundtable worker --url https://roundtable.example --room ROOM_ID --runtime claude-code --workspace C:\work\project
-```
-
-默认只读。实现席位必须同时在房间里获得明确工作区写权限，并在参与端启动时带 `--allow-write`；只有实施阶段才启用写入。审查席位只读。远端工作区路径按参与电脑填写；协调端不会把自己的文件路径当作另一电脑上的项目。
-
-## Pi + 本机 Ollama
-
-安装当前官方 Pi（>=1.1.0），检查 Ollama 已安装的模型，选择支持工具调用的模型：
-
-```powershell
-npm install -g @earendil-works/pi-coding-agent@1.1.0
-ollama pull qwen3:8b
-@'
-FROM qwen3:8b
-PARAMETER num_ctx 32768
-PARAMETER temperature 0
-'@ | Set-Content -LiteralPath .\roundtable.Modelfile -Encoding utf8
-ollama create fuli-roundtable-qwen3-32k -f .\roundtable.Modelfile
-fl roundtable worker --url https://roundtable.example --room ROOM_ID --runtime pi --model fuli-roundtable-qwen3-32k:latest --workspace C:\work\project
-```
-
-这是本次真实测试使用的模型配置。约需下载 5.2 GB；别名共享原模型权重，只为该模型设置 32K 上下文，不修改 Ollama 的全局设置。基本工具测试使用过 16K；完整圆桌的 16K 请求实测超出预算，因此指南推荐 32K。适配器的最低预检要求为 16K；未配置 `num_ctx` 的默认 4K、8K 或更小窗口会明确返回 `model_context_insufficient`。预检通过不代表任意大小的回合都能容纳，完整请求仍会检查预算。也可以选择自己的已安装工具模型；模型名称和实际上下文由预检读取。
-
-Pi 使用工作端本机 `http://127.0.0.1:11434` 的 Ollama；可用 `FULI_PI_BASE_URL` 指定另一个回环端口的 `/v1` 地址。每次调用自动创建并清理隔离的 Pi 配置，不改你的 `~/.pi/agent`。禁用 shell、继承扩展与 MCP，读/编辑/写工具检查准确工作区及 symlink/junction。这里是工具约束，不是操作系统沙盒。允许写入仍需要双重授权。
-
-当 Pi 已执行完工具、最终报告仍不满足圆桌结果契约时，适配器至多调用一次同一本机 Ollama 来整理结果。整理阶段没有工具，产物引用必须对应实际文件证据；明确失败、阻塞或缺少检查证据不能升级为通过。执行和整理共用回合期限，用量分阶段记录，不推算未知的输入或缓存用量。完整证据超出预算时会明确拒绝运行。
-
-当前 Pi / Ollama 为试验接入。Qwen3 的最新严格检查为 3/4，已有 Qwen2.5:14b 对照为 2/4；曾完成 4/4 的运行不代表稳定性。已实际执行读写和路径拒绝，但模型正文可能与真实工具内容不一致，必须由独立审查者检查文件。详细结果见[验证记录](roundtable-beta-validation.md)。
-
-模型安装、工具执行与正确完成任务是不同的验证。模型可能输出错误产物或自报成功，必须由审查者读取实际产物。模型标称上下文也不等于 Ollama 当前加载上下文，可用 `ollama ps` 检查。
-
-Codex 工作端会读取有效 MCP 配置、逐个禁用并再次验证，无法证明隔离时不执行；同时禁用插件、Apps、Hook、通知和继承的额外写入根。保持现有凭据与模型提供商，不改全局配置。可以用 `FULI_CODEX_REASONING_EFFORT=low` 为本次工作端选择受支持的推理强度，不改变其他会话。
-
-## Grok Bot 原生参与
-
-Grok Bot / Team Bot 官方支持自定义 Remote HTTPS MCP。添加如下 MCP URL，并把席位邀请配置为 Authorization Bearer 凭据：
-
-```text
-https://roundtable.example/roundtable-peer/v1/rooms/ROOM_ID/mcp
-```
-
-仅开放 `read_roundtable`、`join_roundtable`、`claim_roundtable_turn`、`submit_roundtable_turn`。让 Bot 加入、读取议题、领取自己的回合并提交结果。读取其他房间、创建邀请或控制本机均不授权。此接入不代表 Fuli 能从外部 API 唤醒既有 Grok Bot；需要 Bot 主动调用 MCP。官方配置见 https://docs.x.ai/grok-bot/team-bots。
-
-## 自动 Grok API 和 A2A
-
-Grok API 是不同入口，使用你自己的 xAI 凭据和模型选择：
-
-```powershell
-$env:XAI_API_KEY = '你已有的 API 凭据'
-$env:XAI_MODEL = '你的账号可用模型'
-fl roundtable worker --url https://roundtable.example --room ROOM_ID --runtime grok
-```
-
-A2A 席位指向公开 Agent Card 可发现的 HTTPS 服务：
-
-```powershell
-# 服务需要认证时，配置 FULI_A2A_TOKEN。
-fl roundtable worker --url https://roundtable.example --room ROOM_ID --runtime a2a --a2a-url https://agent.example
-```
-
-协议适配器不自动拥有对方服务的工具权限。服务需要人工输入/认证、取消未确认或协议不兼容时会显示实际阻塞；不会把模拟答复当作接通。
-
-## 最有说服力的验收
-
-1. 三台电脑，三个独立客户端，各用独立邀请。让 A 生成随机标记，B 引用并质疑，C 总结；退出并重开协调端，确认历史保留。
-2. 协作任务由实现者生成实际文件/提交，再由独立审查者读取并给证据；用户最后验收。模型自报成功与人工接受分开显示。
-3. 暂停时不发新回合，停止时工作端取消自己创建的进程。撤销 B 的邀请后，B 不能继续读历史、领取或提交。
-4. 检查真实执行表：会话、模型、用量只能取自执行端。未报告是未知；API/协议夹具测试不是实际模型调用。
-
-自动化验证：`node --test test/roundtable-*.test.js`。自动测试覆盖真实网络/MCP 会话与 SQLite 并发，但多台物理电脑和真实 Grok Bot 登录仍需你按上述步骤验证。实际发布验收记录会列出已通过的检查和未验证边界。

package/docs/roundtable-beta-validation.md

@@ -1,133 +0,0 @@
-# Agent 圆桌 Beta 验证记录
-
-核验日期：2026-10-09。本页记录已有证据及其范围；发布与 registry 安装包另行核验。
-圆桌已提供讨论、分工、实施、审查和人工验收的流程；Codex 的完整真实运行停在等待用户验收，未代用户接受交付。Pi 混合圆桌的失败记录另列，未计为完成。
-
-## CI 与发布前检查
-
-Beta.1 的圆桌功能源码为 [`e87637f`](https://github.com/JevonsCode/fuli/commit/e87637f5c23db29c70a4d5d55594a6ff5db577a2)，
-[对应 CI](https://github.com/JevonsCode/fuli/actions/runs/37918728225) 已成功结束，包含共享阶段提示和 Pi 结果边界修复。
-下列数字属于该提交。Beta.1 发布时再次通过完整检查；Beta.2 补齐安装后发现的 CLI 帮助问题，其 CI 与发布工作流再次验证，不能用本表代替后续检查。
-
-| 检查 | 结果 | 证据范围 |
-| --- | --- | --- |
-| Node 完整套件 | 1041 项：1033 通过，0 失败，8 跳过 | Linux CI；跳过项没有计为通过 |
-| Vue 套件 | 371 通过 | 组件、状态和交互检查 |
-| Vue typecheck / 构建 | 通过 | 类型及生产资源构建 |
-| Package smoke | 通过 | `npm run test:package` 检查打包产物 |
-| 依赖 audit | 0 漏洞 | CI audit 和本地最终 audit 记录 |
-| Provider 检查 | 通过 | Python Provider 测试及 Compose 配置检查 |
-| 独立代码审查 | 多轮修复后无 P1 / P2 | core、协议、worker、Codex 隔离和 parser；focused 检查 72/72，后续检查 8/8 |
-
-Windows 本机完整套件仍有 29 项失败，失败集合与所比较基线逐项匹配。
-Linux CI 已通过；Windows 完整套件尚未全部通过，环境差异继续保留为验证范围。
-
-Pi 的新增 post-format 路径与共享阶段提示修复已完成独立复审：圆桌回归 87/87、Pi 专项检查 20/20 通过，未发现尚未解决的 P1/P2。真实 Pi grep 工具验证了配置继承导致的越界及其修复；失败状态、产物引用、分歧、取消和上下文预算分别核对。模型正文可靠性仍为试验范围。当前 CI、审查和真实 CLI 证据不自动覆盖后续功能修改，
-GitHub prerelease、npm beta dist-tag、registry / tarball 和官网部署也需分别确认。
-
-### 发布后安装检查
-
-`0.9.0-beta.1` 的公共 npm 包已实际安装到独立临时目录，403 个发布文件的 tarball 完整性验证通过，SHA-1 与发布回执一致：`4943d5b9acbfdce698635b7f487cf6034171ca1a`。Pi 适配器、结果整理器、共享阶段提示和协调端模块均能加载，生产 UI 与验证文档包含在包中。官网已上线圆桌版图，两个版本固定的文档链接返回 HTTP 200，400px 视口未出现横向溢出。
-
-该 registry 包的界面也已在实际浏览器验收：中英文切换、无项目草案创建、Codex / Pi 席位、Pi 的 32K 模型输入、凭据隐藏及确认停止均完成，页面显示 `owner_stopped` / 已停止。测试没有启动模型，没有生成实际运行回执；使用的是隔离测试数据，没有修改用户长期数据。
-
-安装后发现 `fl roundtable worker --help` 被当成未知参数，顶层帮助也漏列 Pi；Beta.2 修复这一入口问题，并重新执行 CLI 回归与发布检查。发布包、运行界面和模型执行各自核验，帮助输出不能算模型执行证据。
-
-## 真实本机 Codex 圆桌
-
-本地回执 `output-roundtable-cli-live-verified.json` 的核验时间为 `2026-10-09T09:20:13.155Z`，
-证据级别为 `real_cli_local_network`。三个独立席位通过本机网络完成以下 7 个执行回合：
-
-| 顺序 | 阶段 | 席位 | 回合状态 |
-| --- | --- | --- | --- |
-| 1 | discussion | 主持人 | completed |
-| 2 | discussion | 实施者 | completed |
-| 3 | discussion | 审查者 | completed |
-| 4 | planning | 主持人 | completed |
-| 5 | implementation | 实施者 | completed |
-| 6 | review | 独立审查者 | completed |
-| 7 | synthesis | 主持人 | completed |
-
-实施者创建 `roundtable-evidence.txt`，独立审查者实际读取并逐字节比较，报告 `passed: true`。
-验收程序也确认文件存在、内容完全匹配：
-
-| 产物检查 | 观察值 |
-| --- | --- |
-| 文件大小 | 52 字节 |
-| SHA-256 | `3de9091873b8023d1fbd83bccd8713cf9a44cfa051f6136f9b8dcd2413b39a1e` |
-| 回合完成 | 7/7 |
-| 独立真实会话 | 7 |
-| 报告用量的回合 | 7 |
-| 实际模型 | 未知；回执中的 `model` 均为空，未用配置值补齐 |
-| 物理电脑 | `physicalComputers=1` |
-| 最终阶段 / 状态 | `synthesis` / `waiting_input` |
-| 等待原因 | `owner_completion_required` |
-| 人工验收 | `not_performed` |
-
-回执将应用标为参与端报告的 Codex，保留 `provenance=participant_reported` 和
-`identityVerified=false`。会话、用量及文件结果有真实运行证据，服务端没有独立认证原生进程身份。
-已注册席位、预检和讨论计划都不单独算执行；这里的实施与审查依据实际回合、工具行为和产物检查。
-
-这次验证覆盖一台电脑上的独立席位与会话，尚未证明多台物理电脑或不同厂商客户端的完整协作。
-独立 reviewer 的通过结论保留为验证报告，用户的人工验收仍待进行。
-
-## Pi 与本地模型
-
-Pi 1.1.0 配合本地 qwen3:8b 已完成 3 项基本真实工具检查。
-`output-pi-basic-live.log` 的汇总为 `passed: true`，本地预检通过，实际调用和会话使用 Pi / Ollama；
-运行回执中的本地模型别名为 `fuli-roundtable-qwen3:latest`。
-
-| 基本检查 | 结果 |
-| --- | --- |
-| 读取已存在文件 | 通过；实际调用 read 并返回文件内容 |
-| 写入指定字面内容 | 通过；实际调用 write，产物检查通过 |
-| 拒绝工作区外路径 | 通过；越界 write 的工具结果为错误 |
-
-上述 3/3 只证明基本读写与路径边界。新增的严格结果整理、执行预算和阶段提示等 Pi 专项检查 20/20 通过，并完成独立复审，
-但真实模型报告仍不稳定：Qwen3 的最新检查为 3/4，已有 Qwen2.5:14b 的一次对照为 2/4。
-Qwen3 曾有两次 4/4；最后一次读取工具实际返回随机标记，主模型及整理模型的正文却复述错误示例，
-该检查如实记为失败，`verification.passed` 保持 false。正确写入及回读、只读和越界拒写有真实工具证据。
-Pi 的正文与产物必须由独立审查者检查，不能把一次成功或合法 JSON 当可靠交付。
-
-混合圆桌的首次运行因 Codex 云端 `workspace routing discovery failed` 停在首轮；Pi 仅预检和加入。
-短时 Codex ACK 恢复通过后，第二次运行完成 Codex 主持首轮；Pi 在模型调用前因完整请求超出 16K
-上下文预算中止，实际用量为 0。两次均没有实施文件、独立审查或汇总，也没有人工验收。
-随后新建共享原权重的 `fuli-roundtable-qwen3-32k:latest`，原模型上限实测为 40960，适配器预检及
-Ollama 运行状态均确认 32768；一次真实只读探测的工具内容和正文均匹配随机标记，无写入。
-所有这些实测都在一台物理电脑上进行。Pi + Ollama 仍为 **experimental（试验接入）**，基本工具或合法输出不能代替完整混合圆桌验收。
-
-### 32K 混合圆桌：真实输出，尚未完成交付
-
-第三次运行记录为 `output-roundtable-mixed-32k.json`，核验时间 `2026-10-09T10:20:51.281Z`。Codex 主持人的讨论回合 `completed`，Pi 使用 `fuli-roundtable-qwen3-32k:latest` 真实生成输出，并报告用量；但 Pi 错把未来 implementation / review 阶段的 `pending` 任务当作当前 discussion 的阻塞，提交 `blocked`。服务最终为 `discussion` / `waiting_input`，原因 `participant_blocked`。`artifactMatches`、`reviewPassed`、`reachedSynthesis` 均为 false，没有完成实施产物、独立审查或汇总，人工验收未进行。
-
-共享阶段提示修复后的运行记录为 `output-roundtable-mixed-phase-fixed.json`，核验时间 `2026-10-09T10:33:57.477Z`。Codex 讨论回合再次 `completed`；Pi 32K CLI 退出码为 0，出现 `agent_settled`，真实生成 input 2391 / output 108 tokens，但原生最终正文验收为 `response_invalid`，尚未进入 formatter。JSONL 会话、模型和用量已解析；日志没有保存最终正文，无法进一步区分 stopReason、空正文或大小限制的具体触发条件。服务停在 `discussion` / `waiting_input`，原因 `participant_failed`；没有实际产物校验值、审查或汇总完成证据，人工验收仍未进行。`physicalComputers=1`；取消请求、worker 收尾、协调端关闭及所拥有工作区清理均有完成记录。
-
-这两次记录证明模型实际运行过，也证明流程仍未通过；CLI 成功退出不等于结果契约有效或协作完成。共享阶段提示已有修复和专项测试证据，Pi 的有效结果与完整混合流程仍需新的真实验证。
-
-## 其他接入与界面边界
-
-| 范围 | 当前证据 | 仍需验证 |
-| --- | --- | --- |
-| Grok API | 按官方 API 契约完成协议 fixture 检查 | 缺少有效凭据的真实模型调用、真实 model / usage 与完整圆桌 |
-| Grok Bot / Team Bot | 官方支持自定义 Remote HTTPS MCP；已提供有限圆桌 MCP 接入步骤 | Bot 的真实登录、配置、主动加入和领取 / 提交回合；尚未 live 验收 |
-| A2A | 官方 SDK 的协议测试 | 独立外部真实服务的发现、任务、产物及取消确认 |
-| Claude Code | 适配器与协议 / 故障检查 | 有效凭据下的完整真实运行及跨平台协作 |
-| 多台物理电脑 | 本机独立网络客户端、HTTP / MCP、SQLite 恢复和授权检查 | 用户在多台电脑上验证可达性、客户端运行、撤销和恢复 |
-| 圆桌页面 | Vue、组件、HTTP 路由、构建检查，以及 IAB 实际页面和 400px 小屏验收（范围见下文） | 其他页面与最终 registry 安装包界面；本次页面验收没有启动模型或取得执行回执 |
-| 官网 | 构建与内容检查 | 实际视觉和小屏验收 |
-
-### 实际页面验收
-
-IAB 已实际打开圆桌页面，完成中英文切换，并通过界面创建无项目草案。中文显示“讨论·独立临时任务”，Codex 与 Pi 分别显示为独立席位。Pi 邀请界面可见模型输入，凭据保持隐藏；执行停止操作后，页面显示“已停止”。
-
-在 400 × 850 视口中，实测 `documentWidth = bodyWidth = 400`，没有横向溢出；截图核对了席位的纵向布局。这次验收覆盖上述圆桌页面操作，尚未覆盖官网、其他页面和最终 registry 安装包界面。
-
-页面验收没有启动模型，也没有执行回执，不能作为模型运行或任务完成的证据。验收使用的静态构建早于 Pi 模型 placeholder 更新为 `fuli-roundtable-qwen3-32k:latest`；该源代码更新另有 focused 组件测试 10 / 10 通过的证据，最终源码 CI 已构建该更新，registry 安装包界面仍需复核。
-
-Grok API 席位与现有 Grok Bot 分别验收。官方 MCP 配置能力证明有接入方式，
-不证明 Bot 已连接，也不提供由外部 API 唤醒现有 Bot 聊天的证据。
-A2A 协议测试不代表完整规范兼容或外部服务已经接通。
-
-后续实际步骤见[跨电脑 Beta 测试](roundtable-beta-testing.md)。测试时分别记录物理电脑、
-运行端、实际会话、模型与用量、产物及审查结果；缺少的数据保持未知。
-本页只公布必要摘要、相对产物名与校验值，不公开凭据、本机绝对路径或原始运行日志。

package/docs/roundtable-research.md

@@ -1,142 +0,0 @@
-# Agent 圆桌接入与开源研究
-
-核实日期：2026-10-09。本文是官方文档、仓库与公开 npm 元数据的研究记录，
-不是接入验收报告；没有启动模型、读取密钥或更改运行配置。
-
-## 建议
-
-采用 Fuli 自有圆桌领域与协调任务，运行时通过统一 participant port 接入。
-完整 beta 应同时提供真实本机 CLI、开放 MCP 参与、远端 A2A、API 模型席位，
-并展示每个入口的实际就绪、执行、取消和证据状态。已有身份、授权、记忆、
-任务验证、租约和时序历史继续由 Fuli 管理。
-
-最适合直接增加的依赖是官方 `@a2a-js/sdk`。群聊、恢复和工具授权借鉴下表的
-设计；不引入另一套框架来接管 Fuli 的记忆和任务真相。此项是结合本项目架构
-作出的工程判断。
-
-## Fuli / Grok Bot / Codex Dot：事实与取舍
-
-“Codex Dot”是用户的称呼；本次官方资料使用的是 **your dot**，未核实独立的同名产品或专属公开 API。下面分别比较官方 dot 与 Codex 能力。本机只读核查确认 `codex-cli 0.162.0-alpha.2` 提供非交互执行、代码审查、MCP 配置及会话恢复入口；这些入口本身不证明任务已执行，真实 Codex 圆桌回合另见[Beta 验证记录](roundtable-beta-validation.md)。[Codex CLI 官方契约](https://learn.chatgpt.com/docs/cli/reference)
-
-| 产品 / 已核实入口 | 强项与适用取舍 | 当前边界 |
-| --- | --- | --- |
-| Fuli Agent 圆桌 | 用户使用自己的电脑、运行端与凭据，通过独立 CLI / API / MCP / A2A 席位围绕共同目标协作；房间内共享且可追溯的消息、分歧、产物和审查接续 Fuli 的身份与知识范围，最终验收由人决定。 | 已提供 Beta 接入与协调流程，完整真实圆桌证据目前来自一台电脑上的 Codex；多电脑和其他运行端的真实协作分别待验收。尚未提供托管常驻服务、默认第三方通讯平台一键入口，也没有 Grok 原生 Bot 的外部唤醒能力。见[接入步骤](roundtable-beta-testing.md)与[证据范围](roundtable-beta-validation.md)。 |
-| 官方 Grok Bot | 常驻云同事适合持续跟进；官方支持 2–6 位 Bot 群聊、异步交接及内部唤醒，笔记本关闭后仍可继续工作。[协作](https://docs.x.ai/grok-bot/chat-and-collaboration)、[FAQ](https://docs.x.ai/grok-bot/faq) | 同一账户的 Bots 共用云电脑、文件和登录，不构成彼此的安全隔离。Custom Remote HTTPS MCP 提供主动接入 Fuli 的方式，但尚未 live 验收；本次核实的官方文档未建立 Fuli 从外部唤醒现有 Bot 的公开契约。[Team Bots](https://docs.x.ai/grok-bot/team-bots) |
-| 官方 your dot 与 Codex | dot 可在对话之间持续跟进、并行委派，创建或续接本地 Codex 任务，也可使用已配置的 Codex 云环境；它有自己的云电脑，适合由一个助手持续协调工作。[任务与记忆](https://learn.chatgpt.com/docs/dots/tasks-and-memory)、[电脑与应用](https://learn.chatgpt.com/docs/dots/computers-and-apps) | 官方当前说明一次可连接一台个人电脑；本地任务要求该电脑在线且 ChatGPT 应用打开，云任务可在本机离线时运行。该能力不能直接推导为独立厂商 CLI / API / MCP / A2A 席位的通用圆桌契约，也不证明本项目已接通 dot。 |
-
-因此，Fuli 的取舍是让不同运行端保留自己的执行入口、权限和证据，在用户可控的协作记录中完成交付；Grok Bot 和 dot 的常驻托管与内建协调更省运维。长期记忆、多 Agent 和调度并非 Fuli 独有；跨运行端接续、可检查的协作过程和人工权威，才是本项目需要持续验证的价值。
-
-## 开源方案与取舍
-
-| 方案 / 官方来源 | 当前能力与许可证 | Fuli 应采用什么 | 集成代价与边界 |
-| --- | --- | --- | --- |
-| [A2A JavaScript SDK](https://github.com/a2aproject/a2a-js) | Apache-2.0；A2A v1.0，JSON-RPC、REST、gRPC；v0.3 兼容需显式开启 | **直接集成客户端适配器**：Agent Card、任务、流、产物、取消；必要时以相同领域操作托管服务端 | Node >=20；JSON-RPC/REST 客户端不需要 Express、gRPC 或 SQL 数据库。协议不会替用户登录或操纵封闭客户端 |
-| [Microsoft Agent Framework](https://github.com/microsoft/agent-framework)、[A2A 接入](https://github.com/microsoft/agent-framework/blob/main/python/packages/a2a/README.md)、[许可证](https://github.com/microsoft/agent-framework/blob/main/LICENSE) | MIT；Python/.NET；开放模型提供方、工作流、MCP 与远端 A2A 包装 | 借鉴远端 Agent 能力包装；把外部 MAF 服务作为 A2A 席位 | 整体引入会增加 Python/.NET 编排与生命周期；本项目 JS 应用层已有相关职责。核实具体 A2A 包版本，不能从框架总版本推断兼容性 |
-| [LangGraphJS](https://github.com/langchain-ai/langgraphjs)、[interrupt](https://docs.langchain.com/oss/javascript/langgraph/interrupts) | MIT；有状态图、持久检查点、暂停和恢复；可不依赖 LangChain | 借鉴可验证阶段转换、等待用户和恢复设计；复杂新工作流可另行使用 | Fuli 现有任务和圆桌存储已具状态权威，引入会新增检查点同步责任。恢复节点会重跑 interrupt 前代码，副作用仍必须幂等 |
-| [AutoGen](https://github.com/microsoft/autogen) | 代码 MIT；文档存在 CC-BY-4.0；Python AgentChat/Core，群聊、分布式运行时 | 借鉴轮流/点名发言和组合终止条件 | 官方仓库已标明维护模式，不新增功能，推荐新项目用 Agent Framework；因此不选作新产品底座 |
-| [CrewAI](https://github.com/crewAIInc/crewAI)、[A2A](https://docs.crewai.com/en/learn/a2a-agent-delegation) | MIT；Python 角色任务、流程；`crewai[a2a]` 可代理远端 Agent，也可托管 A2A Agent | 借鉴单一任务负责人、预期产物和阶段交接；远端 CrewAI 服务通过 A2A 接入 | 应用内多模型协作与用户已有客户端互通是不同验收目标；整体引入增添 Python 运行时、记忆与工具策略 |
-| [OpenClaw](https://github.com/openclaw/openclaw)、[CLI backends](https://docs.openclaw.ai/gateway/cli-backends)、[remote node](https://github.com/openclaw/openclaw/blob/main/docs/cli/node.md) | MIT，另有第三方 notices；Gateway、可更换模型/harness、消息渠道和远端节点 | **重点借鉴运行时边界**：CLI JSONL、私有 MCP 配置、当前尝试有效的接入 grant；外部 OpenClaw 可成为受限席位 | 自身是完整常驻 Gateway；不需要把它捆进 Fuli。远端节点执行命令需配对授权，不等同跨厂商既有聊天 API |
-| [OpenBot](https://github.com/CopilotKit/OpenBot)、[配置](https://github.com/CopilotKit/OpenBot/blob/main/docs/configuration.md)、[许可证](https://github.com/CopilotKit/OpenBot/blob/main/LICENSE) | MIT 的早期模板；每位 coworker 独立电脑，AG-UI 远端 Agent、授权与记录 | 借鉴明确授权、电脑/文件边界和显示真实活动；AG-UI 可作为独立未来 UI 适配方向 | 私有 workspaces，没有可依赖发布包；需 Docker、Bun、Postgres 和 CopilotKit Intelligence 项目。Intelligence 依赖及 entitlement 不因模板 MIT 自动消失 |
-| [Google ADK JS](https://github.com/google/adk-js) | Apache-2.0；Node >=20.19；顺序/并行/循环 Agent、MCP、A2A | 外部 ADK Agent 可直接走 A2A；借鉴清晰工具 schema | 与现有 Fuli 编排重复；不需要为接入一个远端 Agent 把整个 ADK 引入 |
-| [ACP TypeScript SDK](https://github.com/agentclientprotocol/typescript-sdk) | Apache-2.0；编辑器与 coding Agent 间的会话、权限与更新协议；v1 稳定，v2 明确是草案 | 支持 ACP 的 coding Agent 可加独立 participant adapter | ACP 解决客户端控制 coding Agent 的问题；A2A 解决独立 Agent 的远端任务契约。应各自报告实际协商能力，不把实验 v2 当已稳定支持 |
-
-许可证记录描述上述仓库本身；引入代码须保留相应 LICENSE/NOTICE，模型服务、
-托管平台与可选组件仍按各自条款。当前决定仅直接引入官方 A2A SDK，其他条目
-作为设计来源或外部端点，不复制框架代码。
-
-## A2A 适配具体决定
-
-公开 npm `latest` 元数据于本次读取为 `@a2a-js/sdk@1.3.0`；唯一必需 runtime
-依赖为 `jose`，Express、gRPC、Kysely 与数据库驱动都是 optional peers。
-见[官方 package.json](https://github.com/a2aproject/a2a-js/blob/main/package.json)。
-实现应锁定并测试实际安装版本，避免使用旧 0.3 SDK 示例来构建 1.x 接口。
-
-采用 `ClientFactory` 配合 `JsonRpcTransportFactory` / `RestTransportFactory`，
-通过 Agent Card 选择支持的接口。`sendMessage` / `sendMessageStream` / `getTask`
-与 `cancelTask` 支持每次请求的 signal 和 serviceParameters headers。
-SDK 提供认证重试辅助器；Fuli 不自动采用其 401/403 重试行为，因为认证失败
-需要明确转入 waiting_auth。上述契约见[官方 SDK 文档](https://github.com/a2aproject/a2a-js)。
-
-建议映射：describe 保存真实 Agent Card 能力；preflight 做发现/认证和版本检查；
-dispatch 保存远端真实 task/context ID；observe 转换 task/status/artifact 事件；
-cancel 请求远端取消，只有收到对应终态才显示确认停止。AbortSignal 中止本地
-网络等待不证明远端工作停止。room/seat/turn/attempt/fence 与远端 ID 的关联由
-Fuli 持久化；远端 completed 只能完成该回合，不能越过 Fuli 协调任务验证。
-
-不要默认启用 push webhook 或另外增加 SDK SQL task store；当前 Provider 已有
-存储权威。若后续托管 Fuli A2A 服务端，应通过注入 store 与领域端口接入既有
-存储，避免第二份任务完成状态。端点与鉴权只从明确配置读取，不自动发现私人
-端点或从 Agent Card 声明扩大权限。
-
-## Grok Bot、Grok API 与第三方 grokbot
-
-**Grok Bot 是真实的官方产品。** 官方[概览](https://docs.x.ai/grok-bot/overview)
-描述长期保留的 AI 同事与云电脑。[协作文档](https://docs.x.ai/grok-bot/chat-and-collaboration)
-明确支持 2–6 位 Bot 群聊、点名、异步交接和接收 Bot 唤醒。[FAQ](https://docs.x.ai/grok-bot/faq)
-同时说明：同一账户的 Bots 共用一台持久云电脑、文件、浏览器会话和登录，不能
-把不同 Bot 当安全隔离边界；关闭笔记本后后台工作仍可继续。
-
-官方[Team Bots 插件表](https://docs.x.ai/grok-bot/team-bots)明确列出 Custom MCP
-server 的 Remote HTTPS 与 Command 两种方式；HTTPS 可使用 Bot 自身凭据或
-按用户 OAuth，Command 在会话使用的云电脑运行。这证明 Grok Bot 可以配置
-Fuli 的远程有限圆桌 MCP 工具，主动读取/接受/提交自己的席位回合。
-
-本次查阅的 Bot 文档没有提供外部系统向现有 Bot 发消息或启动其后台回合的
-公开编程契约；内部 Bot-to-Bot 唤醒不能推导为 Fuli 拥有相同外部控制能力。
-因此 native Grok Bot 接入以实际 MCP 会话参与为证据，不把配置可用或 API
-模型输出展示为“原生 Grok Bot 已自动参与”。这是一项当前文档边界，后续发现
-正式 Bot API 时可增加独立适配器。
-
-GitHub 的 [xlviitheroman/grokbot](https://github.com/xlviitheroman/grokbot)是
-第三方 Discord Bot，README 使用 `DISCORD_TOKEN` 和 `GROK_API_KEY`，与官方
-Grok Bot 产品不同；不选其作为跨 Agent 编排或官方 Bot 接入依据。
-
-## 自动 Grok API 席位
-
-xAI API 与用户已有 Grok Bot 是两个入口。自动 API 席位应显示提供方、实际
-model、真实请求 ID、usage 与结果，来源明确写为 Grok API。
-
-[Quickstart](https://docs.x.ai/developers/quickstart)与
-[Remote MCP](https://docs.x.ai/developers/tools/remote-mcp)使用 `XAI_API_KEY`、
-`https://api.x.ai/v1` 和 Bearer authentication。官方当前示例为 `grok-4.7`；
-应允许配置并通过[模型目录](https://docs.x.ai/developers/models)预检，不能
-把旧模型名称视为永久可用。新版适配优先 `/responses`；
-[Chat Completions](https://docs.x.ai/developers/model-capabilities/legacy/chat-completions)
-官方已标注 legacy，新功能先进入 Responses。
-
-[Function Calling](https://docs.x.ai/developers/tools/function-calling)支持自定义
-JSON Schema function tools、auto/required/none/指定工具选择，默认允许一次多
-工具调用，可用 `parallel_tool_calls: false` 禁止。由 Fuli 管理的本地 tool loop
-只执行 seat allowlist，校验参数与授权，回传每个 call ID 的结果，并硬限制调用
-次数与时间。模型提出工具调用不是已执行证据。
-
-[Remote MCP](https://docs.x.ai/developers/tools/remote-mcp)支持 xAI native SDK 和
-OpenAI-compatible Responses；服务器连接由 xAI 执行，仅 Streaming HTTP/SSE，
-支持 authorization/headers 和 allowed_tools。空或缺失 allowlist 会开放全部
-服务器工具；`require_approval` 和 `connector_id` 当前不支持。Fuli 因此需要
-自己执行授权和有限工具服务，不能把 API 不支持的 approval 字段当安全门槛。
-只有从 xAI 可达的明确授权 HTTPS 端点才能用此路径；本机 loopback/stdio 可
-通过 Fuli 自己的本地 tool loop 处理，不应宣称云端能访问本机。
-
-凭据配置只存环境变量名或既有 secret reference；不在房间、日志、状态响应、
-提示词或研究记录中保存值。HTTP 401/403 转为等待授权，400/422 参数错误和
-404 模型/端点错误不盲目重试。429 与可恢复传输故障可在本次预算内至多一次
-退避重试；执行副作用后状态不明时先 observe，不能重新 dispatch 制造重复。
-错误语义见[xAI Debugging](https://docs.x.ai/developers/debugging)；重试次数是
-本项目设计策略，不是 xAI 默认承诺。
-
-## Beta 验收证据
-
-Pi 官方仓库已迁移到 [earendil-works/pi](https://github.com/earendil-works/pi)，MIT 许可。当前 CLI npm 包为 `@earendil-works/pi-coding-agent`；本适配器需要 >=1.1.0 的项目批准与资源隔离选项。Pi 保留独立执行入口，Ollama 提供本地推理；接入不依赖另一个长期记忆系统。Ollama 的 [Chat API](https://docs.ollama.com/api/chat)支持工具与结构化输出；实际工具调用和最终格式可靠性仍需分开验收。
-
-- 独立本机 CLI 要证明真实提案、审查、修订及任务产物；真实凭据不足记为阻塞。
-- native MCP 席位要证明独立认证会话的跨席位消息和回合流；可复制配置不算已连接。
-- A2A 要用独立服务证明 discovery、task 生命周期、流/轮询、input/auth 等待、
-  artifacts、取消确认与过期结果隔离；本地 fixture 明确标为协议测试。
-- Grok API 真实调用需要报告真实 model/ID/usage；无 API 凭据仅验证 parser、
-  错误映射和协议，不能报告已真实模型验收。
-- Grok Bot 插件配置及主动圆桌回合必须用其真实客户端证明；未经验证的外部
-  自动唤醒、封闭聊天移交、全天托管和跨组织隔离均不能成为发布承诺。
-
-这些证据级别可同时存在。完整 beta 是包含接入、授权、状态、恢复、停止与
-交付的产品；协议或模拟测试不能代替相应真实运行验证。