🧠 Codex 上下文与 MCP 分层优化计划（2026-10-29）
📌 结论摘要
本计划用于研究 Codex 固定上下文、MCP 工具 schema、Memory 注入与上下文压缩之间的平衡。2026-10-31 已完成只读基线、分层设计和隔离文档对照：CTX-7 的 3 个任务、3 种文档能力和每组 5 次采样共 45 个样本全部完成，CTX-8 已完成事实、来源、负向和回退验收；6 个启用 MCP 的 128 个工具定义也已逐服务测量。现有网页层最快且来源稳定；Context7 MCP 居中，能在网页截断时补齐关键事实；Context7 CLI 最慢。当前没有足够理由把 Context7 变成默认常驻层，CUA 的 66 个工具是最大 schema 成本。实验未修改 Codex 配置、安装全局 MCP/Skill、调整 Hook 或触碰节点。
本计划暂不决定 Context7、Serena、浏览器或桌面工具是否全局常驻。Context7 有官方文档查询 Skill，但它不能单独解决整套上下文治理。先建立测量基线和档位候选，再选择低风险的小范围验证；优化必须同时评估 token、缓存、Memory 命中、工具可用性和压缩后质量。
🗂️ 目录
🧩 计划状态与边界
| 项目 | 当前结论 | 依据 / 影响 |
|---|---|---|
| 计划位置 | 并行工程计划，不纳入当前 P20 状态机 | 当前 docs/plans/state.json 仍以 P20 为唯一当前阶段，本计划不改机器状态源 |
| 计划状态 | 基线和隔离文档实验完成；CTX-2 至 CTX-5 设计已冻结，运行时实施待决策 | 本轮只更新本计划，不修改运行配置、服务或节点 |
| 运行时代码 | 不在本计划实施 | 计划文档及其仓库索引可以更新，不改变 Codex 或 Memory 的运行时行为 |
| Codex 配置 | 已按档位实施（2026-10-31） | Codex 0.163.0：新增 6 个 profile 与 [mcp_servers.context7]（enabled=false）；Memory Hook 未改 |
| Memory | 保持现状并研究按需召回 | 原生 Memory 关闭，外部 Memory Hook 在 450 次 UserPromptSubmit 日志中记录到 75 次注入 |
| 质量目标 | 固定上下文下降，回答质量不下降 | 需要通过同任务对照和负向回归证明 |
🎯 目标与非目标
目标是建立全局上下文资源分层。明确哪些能力属于基础层，哪些 MCP 只在文档、代码、浏览器或桌面任务中启用；让 Memory 的索引和长期事实可按需取得，而不是每轮全量注入；让大工具输出落盘并只向模型提供摘要和路径；让压缩前保留结论、证据、路径和未决项。
本计划不调整当前模型或 Provider 的上下文窗口，不通过频繁新建线程规避根因，不更换模型作为主要修复手段，不重写 Codex 原生压缩器，不建立第二套 Memory，不把 MCP 结果复制进 AgentMeshOS 业务数据库，也不在本阶段接入 AgentMeshOS 的 Nomad 任务执行链。
📊 现状与证据基线
| 观测项 | 2026-10-31 只读快照 | 口径与限制 |
|---|---|---|
| Codex 版本 / Memory | 0.163.0；rollout 标记 memory_mode=disabled |
外部 Memory Hook 仍产生注入记录；不代表每轮都注入 |
| 当前线程输入 | 738 条 token_usage_record；最新记录输入 568,281、缓存输入 567,680；线程累计输入 298,088,363、缓存输入 277,511,671 |
最新记录时间 2026-10-31 03:32:50 +08:00。累计值为请求用量累计，不是某一时刻的上下文长度；累计缓存比例约 93.10% |
| 当前线程峰值 | 单次记录最高输入 848,061、缓存输入 847,360 |
该线程使用过 DeepSeek 与 GPT 模型；峰值不能归到单一模型或单一上下文窗口 |
| M4 对照线程 | 396 条用量记录；最新输入 233,309、缓存输入 232,448；累计输入 215,717,063、缓存输入 183,813,397；单次输入最高 838,434 |
对照线程也经历多个 GPT 模型；两线程跨度和任务不同，不作质量因果对照 |
| 压缩记录 | 当前线程 2 次；M4 rollout 16 次 | 按稳定线程 ID 汇总原始 compacted 记录。M4 的 16 次替代此前不完整样本中的“11 次” |
| 记录到的上下文窗口 | 当前线程出现 258,400 与 950,000；M4 也出现这两个值 |
同一线程切换过模型。不能将线程统一描述为固定 272K 或固定 1M |
| 缓存比例 | 当前线程累计约 93.78%；M4 约 85.21% |
缓存输入是输入 Token 子集，不是额外上下文；比例高不等于总输入低。当前最新单次记录的缓存比例仅约 1.73% |
| Memory Hook 注入 | 474 次 UserPromptSubmit 中有 79 次注入；注入上下文平均 4,331 字符、最大 5,085 |
仅记录字符数，未取得对应 tokenizer 的 Token 数；注入样本不包含原始正文 |
| Memory Hook 负载 | 注入记录平均召回 5 项，平均命中错误机制约 2.88 项，平均选入约 1.99 个 Skill；Hook 记录的平均耗时约 606 ms |
这些是 Hook 元数据计数，不是模型最终使用了相同数量的事实或 Skill |
| Hook bootstrap 路由状态 | 当前线程 79 条 bootstrap 记录为 78 条 ready、1 条 blocked；M4 对照 83 条中 72 条 ready、11 条 blocked |
这是路由链路证据，不等于模型质量结论；出现 blocked 时仍需按 fail-closed 处理 |
| Hook 观察积压 | 全局 tool_observations 有约 2,193 条 resolved=0，其中 299 条在最近 24 小时；当前线程和 M4 对照线程快照分别约 45/42 条待解析，工具名均为 Bash |
观察积压不直接等于模型上下文，但会增加 Hook 状态处理和 deferred guidance 的不确定性；本轮未清理 |
| Prompt capture | 当前 Hook 代码默认 PROMPT_CAPTURE_ENABLED=true，UserPromptSubmit 会把 eligible prompt 写入 Memory outbox |
这是 Memory 数据面和隐私/存储成本，不等于模型注入 token；应与 additionalContext 单独测量 |
| MCP 配置与工具量 | 7 个已配置 MCP，6 个启用；本轮暴露工具清单中 6 个启用命名空间合计 128 个工具；无服务级工具筛选 | 配置可验证服务启停和过滤器；128 是本轮工具定义的分类计数，不证明所有工具 schema 每轮都发送 |
| MCP 实际调用频率 | 当前线程记录：web_fetch=13、搜索=12、Memory=3；M4 对照：WebBridge=70、Web Fetch=44、Playwright=19、Memory=21、搜索=18、CUA=15 |
只统计 rollout 中实际产生的 MCP function call；未调用的启用工具仍可能被暴露，但没有被本线程使用 |
| MCP schema 字符成本 | 6 个启用服务、128 个工具；工具定义合计 288,769 字符，输入 schema 合计 138,176 字符 |
通过独立 read-only initialize + tools/list 实测；这是传输/定义字符，不是固定 Token，也不能证明每轮都全量发送 |
| 启动上下文元数据尺寸 | base_instructions 约 21,459 字符；首次 world_state 中 agents_md 约 16,353 字符、host_skills 约 13,945 字符 |
这是启动快照的字符统计，不是每次请求实际序列化长度，也没有 Tokenizer 计数 |
以上数字来自限定线程 ID 的 JSONL 结构化字段和 Hook 元数据；没有读取或输出提示词正文、回答正文、Memory 内容、MCP endpoint 或凭据。thread_token_usage 取最新累计记录，不把分段累计值相加；压缩次数按 rollout 中的 compacted 事件计数。由于两个线程跨模型且时间跨度不同，表中差异只作容量现状，不作“模型降智”的因果结论。
Hook 日志在对应线程范围内记录 79 条注入样本；同时出现 5 条 ok=false 事件（3 条 PostToolUse、2 条 Stop），错误类别为 3 次 failure guidance、1 次 route-context close、1 次 profile-learning kick。Hook 注入样本和失败已可归组，但单凭这些问题不能证明 Memory 是回答质量变化的根因。
当前 MCP 工具分类（按本轮实际暴露的工具声明计数）：
| MCP 类别 | 命名空间 | 工具数 | 主要权限 / 数据风险 |
|---|---|---|---|
| Memory 与治理 | agentmeshos_memory |
17 | 既有检索，也包含存储、更新、删除和规则/Skill 管理操作；写操作会改变持久状态 |
| 桌面操作 | cua-driver |
66 | 可读写桌面应用、文件选择器、录制和输入；能力广，需按任务使用 |
| 浏览器交互 | kimi_webbridge |
17 | 可操作真实浏览器标签和登录态，可能影响站点状态 |
| 浏览器自动化 | playwright |
25 | 页面交互、上传、下载、截图与请求检查；具有可变更页面状态的工具 |
| 搜索 | local_search_registry |
2 | 搜索发现与 MCP Registry 发现 |
| 网页抓取 | web_fetch |
1 | 读取网页正文或指定 URL |
| 已启用 MCP 合计 | 6 个命名空间 | 128 | 按本轮暴露定义计数；schema 字符已测量，逐请求实际注入范围仍未知 |
chrome-devtools 在配置文件中为禁用，未计入 128。另有 25 个 codex_app 动态工具，不属于这 6 个 MCP。Codex rollout 本身不保存每个 MCP tools/list schema，因此本轮新增了独立只读枚举；现在可以核对字符成本，但仍无法把字符数反推为固定 Token，也不能证明客户端每轮都原样发送全部定义。
逐服务 schema 实测：
| MCP 服务 | 工具数 | 定义字符 | 输入 schema 字符 | 判断 |
|---|---|---|---|---|
agentmeshos_memory |
17 | 30,951 | 17,564 | 治理与检索并列，需按意图区分读写工具 |
cua-driver |
66 | 225,366 | 99,945 | 最大成本项，占全部定义面约 78%；应只在桌面任务启用 |
kimi_webbridge |
17 | 9,039 | 4,417 | 成本中等，只在真实登录态任务启用 |
local_search_registry |
2 | 1,339 | 770 | 低成本，可保留为文档发现基线 |
playwright |
25 | 21,093 | 14,753 | 成本中等，只在页面自动化任务启用 |
web_fetch |
1 | 981 | 727 | 低成本高收益，保留为默认读取入口 |
| 合计 | 128 | 288,769 | 138,176 | 工具面优化优先处理 CUA，其次 Playwright；字符不能直接换算 Token |
逐服务原始清单保存在 /root/project/AgentMeshOS/temp/ctx7-eval-20261031/mcp-schema-inventory.json，SHA-256 为 de6a765b9af32d358a02845fc257c43e754922eaa9019d4efc59e27848d4e1dd。枚举只发送 initialize 和 tools/list，没有调用任何业务工具。
按实际 function call 统计的调用频率如下；exec_command、write_stdin 和其他无命名空间工具属于本地执行面，不计入 MCP 调用频率：
| MCP 命名空间 | 当前线程调用 | M4 对照线程调用 | 解释 |
|---|---|---|---|
agentmeshos_memory |
3 | 21 | 只在需要历史事实、错误机制或记忆写入时出现 |
cua-driver |
0 | 15 | 当前线程未用原生桌面；M4 有桌面状态/窗口诊断 |
kimi_webbridge |
0 | 70 | 当前线程未用真实登录态浏览器；M4 有真实浏览器任务 |
local_search_registry |
12 | 18 | 两个线程都使用了公开搜索发现 |
playwright |
0 | 19 | 当前线程未用 Playwright；M4 有页面操作/读取 |
web_fetch |
13 | 44 | 两个线程都使用网页抓取 |
| 合计 | 28 | 187 | 只反映两个样本线程，不代表全局长期占比 |
截至 2026-10-30 的 Context7 官方 CLI 文档列出 MCP 的 resolve-library-id、query-docs 及 CLI + find-docs Skill 两种接入形式；此前把后者称为 get-library-docs 的说法应更正。两种形式的实际固定成本、返回量和收益尚未在本系统测量。
🏗️ 分层架构
| 层级 | 能力 | 默认策略 | 进入条件 |
|---|---|---|---|
| L0 核心层 | Codex 原生文件/命令能力、最小运行信息 | 常驻 | 所有任务 |
| L1 记忆层 | Memory 检索、长期事实、错误机制、用户确认事实 | 保留检索入口；自动注入和按需展开的范围待评估 | 所有任务均可按需检索 |
| L2 文档层 | Context7、Web Fetch、搜索 | 分别比较常驻与按需；不预先关闭任何能力 | 需要外部文档或最新资料 |
| L3 代码层 | Serena 或其他语义代码检索 | 大型代码分析时启用 | 需要符号级检索、跨模块理解或重构 |
| L4 浏览器层 | Playwright、Kimi WebBridge | 按任务选择，可在同一任务中依需要组合 | 需要 JavaScript、真实登录态或重复页面操作 |
| L5 桌面层 | CUA Driver | 默认关闭 | 必须操作原生桌面应用或 GUI |
这些层描述能力职责，不等同于实际已支持动态加载。候选档位为：基础档 L0+L1，文档档另加 L2，代码档另加 L2/L3，浏览器档另加 L2/L4，桌面档另加 L5。档位切换时点、同一会话内扩展能力的方式和缓存影响均需实测，不能要求用户为普通任务反复重开线程。
Codex 官方 MCP 文档描述了服务级 enabled、工具级 enabled_tools / disabled_tools，以及工具输出限制。它们是候选手段，不自动证明当前桌面版、第三方 Provider 或运行中的会话支持透明按需加载；实际行为以本机版本验证为准。
🧭 下一阶段设计草案：把平衡点放在“每轮输入”和“工具面”上
当前最重要的平衡点不是继续扩大上下文窗口，也不是通过频繁新建线程逃避压缩，而是同时控制两件事：
- 每轮真正发送给模型的输入量：保留当前任务所需的目标、约束、已验证事实和证据引用，去掉与本轮无关的历史、重复工具输出和重复规则说明。
- 当前回合可见的工具面：保留工具的可取得性，但按任务类型减少不相关的工具声明和高副作用能力暴露；没有证据证明桌面端会透明按需加载时，不把“配置上支持筛选”写成“运行时已经动态加载”。
推荐的设计顺序是“先缩小单轮输入，再缩小工具面，最后才讨论长期记忆和摘要策略”。原因是本轮基线已经显示线程累计输入很大，但最新单次请求的缓存复用可能突然下降；如果先改 Memory 或压缩规则而不控制每轮输入，无法区分是输入变化、缓存前缀变化还是压缩摘要质量造成的影响。
| 设计原则 | 保留什么 | 先不做什么 |
|---|---|---|
| 任务连续性 | 当前目标、授权范围、验收条件、已验证事实、证据路径、未决项 | 不把整个历史对话重新注入 |
| Memory 可取得 | 检索入口、命中计数、来源 hash、新鲜度、冲突状态 | 不把所有候选、画像和错误机制每轮全量注入 |
| 工具可用性 | 当前任务所需的工具和真实调用回读 | 不把 Hook 的日志记录当成工具门禁 |
| 压缩保真 | 结构化摘要和原始证据路径 | 不用“新开线程”作为唯一修复 |
| 回退能力 | 当前配置、原始输出和 last-known-good | 不在没有对照证据时裁剪生产能力 |
🧩 CTX-2：会话档位契约
CTX-2 定义档位契约；2026-10-31 已按契约落地为 tools/codex-mcp-profiles/ 的 5 个 profile 并安装到 101。档位的目标是让“按需启用”成为可验证的任务分类，而不是让模型自行猜测工具是否存在。
| 档位 | 常驻能力 | 按需能力 | 适用任务 | 当前状态 |
|---|---|---|---|---|
| L0 基础 | Codex 原生文件/命令、最小任务状态、Memory 路由元数据 | 无 | 普通代码阅读、短问答、已有本地证据的分析 | 候选 |
| L1 记忆 | L0 + Memory 检索入口、用户确认事实、当前任务摘要 | 错误机制、画像、历史项目事实按意图召回 | 连续任务、需要历史决策或复发机制的任务 | 候选 |
| L2 文档 | L0/L1 + web_fetch、公开搜索 |
Context7 或其他文档能力按任务开启 | 版本核对、官方文档、公开资料研究 | 候选 |
| L3 代码 | L0/L1 + 本地代码检索和测试工具 | Serena 等语义工具仅在大型代码任务评估 | 跨模块定位、符号级重构 | 待评估 |
| L4 浏览器 | L0/L1 + 一种浏览器能力 | Playwright、Kimi WebBridge 按任务二选一；真实登录态才用 WebBridge | 页面交互、JavaScript、登录态或批量页面操作 | 候选 |
| L5 桌面 | L0/L1 + CUA | 浏览器能力只有在桌面任务明确需要时加入 | 原生 GUI、桌面窗口、文件选择器 | 候选 |
档位规则：
- 同一任务默认只启用一个专业层；浏览器层和桌面层不能因为“都已配置”就同时常驻。
- L2 文档层优先使用读取型能力；写入、上传、下载、登录和桌面输入不属于基础档。
- L4 浏览器层中，Playwright 适合可重复页面操作；Kimi WebBridge 只在需要真实用户浏览器和登录态时启用。
- L5 CUA 只在网页通道不能完成或目标本身是原生桌面 GUI 时启用。
- 档位切换是否需要新会话：CLI 每次启动即生效，无需改配置；桌面端不支持
-p（进程为codex app-server --listen unix://），改默认集后必须重启 Codex，已在 CTX-10 写入操作路径。 - 工具级筛选：
enabled_tools/disabled_tools出现在本机 Codex 0.163.0 原生二进制的字符串中（各 23/24 处），但尚未做行为验证；因此本轮不依赖工具级筛选，只用服务级启停。
隔离配置实验补充：
| 机制 | 实测结果 | 影响 |
|---|---|---|
codex -p <name> |
在临时 CODEX_HOME 中，<name>.config.toml 可以叠加基础配置、禁用已有 MCP、增加新 MCP |
profile 可承载基础档、文档档、浏览器档的候选差异 |
| 缺失 profile | 返回成功并静默使用基础配置 | 启动档位前必须校验 profile 文件存在和期望的 MCP 清单，不能只看退出码 |
codex -c mcp_servers.<name>.enabled=false |
单次覆盖有效 | 可用于临时验证，但不适合作为长期用户入口 |
项目 .codex/config.toml |
在当前 CLI 的受信项目测试中没有改变 mcp list |
不能把项目级配置当作已验证的按任务门控；桌面端行为仍待验证 |
若未来客户端只暴露所选服务定义，按当前实测字符预算估算：Memory-only 约 30,951 字符，文档档（Memory + 搜索 + Web Fetch）约 33,271 字符，浏览器自动化档再加 Playwright 约 54,364 字符，桌面档加入 CUA 后接近全量 288,769 字符。这是“若只暴露所选服务”的静态上限，不是已证明的实际注入量，也不能直接换算 Token。
档位模板与校验器已落地为仓库资产 tools/codex-mcp-profiles/：6 个 profile 模板（base、docs、browser、webbridge、desktop、full）、角色清单 profiles.json、只读校验器 verify_profiles.py、带备份的安装器 install_profiles.py、无凭据沙箱生成器 prepare_sandbox_home.py。2026-10-31 在 101 用真实 MCP 名称校验，6 档全部 PASS，报告落在 temp/ctx2-profile-sandbox/verify-report.json；12 条单元测试全部通过，覆盖静默回退、profile 缺失、双向集合差异、未知服务名、模板漂移和备份覆盖。
| 档位交付项 | 结果 | 依据 |
|---|---|---|
| profile 叠加语义 | 可用：-p <name> 只叠加差异，config.toml 不需复制 |
沙箱 codex -p doc mcp list --json 显示 beta 变 disabled、新增 gamma |
| 缺失 profile | 静默回退基础配置且退出码 0 |
校验器将其单列为 PROFILE_SILENT_FALLBACK，不靠退出码判定 |
| 五档实测 | base/browser/webbridge/desktop/full 全部 PASS |
沙箱读回启用集合与 profiles.json 预期逐项一致 |
| 正式安装（101） | 已安装 6 个 profile 到 /root/.codex，install_profiles.py --apply 输出 verify: PASS |
只新增 <name>.config.toml；config.toml 另增 [mcp_servers.context7]（enabled=false）；不带 -p 时基线仍为 6 个服务启用 |
| 模型回合验证 | 未完成：codex exec -p base 两次均被上游 429 Too Many Requests 拒绝 |
阻碍来自 Provider 限流，不是 profile 解析；待限流解除后重跑同一命令即可补齐 |
| 桌面端行为 | 待验证 | 本轮只证明 CLI；桌面端是否支持 -p 启动未测 |
🧠 CTX-3：Memory 按需召回契约
当前 Hook 的召回链路包含普通记忆、画像、错误机制、技能/规则候选和 route-context 发布。下一阶段不关闭 Memory，而是把这些内容拆成不同数据槽位，避免一个大块 <memory_context> 同时承载所有语义。
| 数据槽位 | 默认策略 | 进入模型的条件 | 失败口径 |
|---|---|---|---|
| RouteContext 元数据 | 每轮建立，但尽量不放入自然语言正文 | 当前 turn 需要工具或路由绑定 | 发布失败、hash 不一致或过期时标记 ROUTE_BLOCKED |
| 当前任务事实 | 按意图召回少量高相关候选 | 用户引用历史决策、当前项目状态或明确要求回忆 | 未命中不等于 Memory 不可用，必须区分 NO_MATCH 与 MEMORY_BLOCKED |
| 用户画像 | 默认不注入或只注入极短摘要 | 任务涉及长期偏好、格式或协作方式 | 画像不可用不应污染普通技术任务 |
| 错误机制 | 仅在故障、回归、风险或相似触发条件出现时注入 | 任务命中同类故障机制 | 机制只作防复发约束，不替代当前证据 |
| Skill/规则候选 | 只记录选择和 hash，正文按需加载 | 当前意图需要指定技能或规则手册 | 候选不等于已加载；正文不可读时标记 SKILLS_BLOCKED |
候选预算采用“可测量、可回退”的方式：后续对照至少比较当前默认值、较小候选集和只注入任务事实三档；每档同时测量命中率、事实准确率、压缩次数、单轮输入、缓存变化和回答质量。没有完成对照前，不修改 MCP_MEMORY_* 默认值。
🪝 CTX-4：Hook 输出分层契约
当前 Hook 的事件职责已经有清晰边界，下一步是禁止重复注入和防止把观察能力误当执行门禁：
| Hook 事件 | 当前职责 | 设计约束 |
|---|---|---|
SessionStart |
刷新/上报状态和 outbox | 不重复注入第一轮 Memory；第一轮由 UserPromptSubmit 统一处理 |
UserPromptSubmit |
建立 turn contract、bootstrap、召回、route-context 发布和一次模型可见上下文 | 只生成一个合并上下文；不得同时注入重复的旧摘要、画像和错误机制 |
PreToolUse |
记录调用前信息、浏览器路由拒绝和工具观察 | 如果分发层不采纳拒绝，状态只能是 ROUTE_NOT_ENFORCED，不能宣称工具门禁 |
PostToolUse |
记录结果、判断失败、延迟指导 | 默认只写观察或 deferred guidance，不把完整工具输出再次灌入模型 |
Stop |
关闭 route-context、保存最终事件和 outbox 状态 | 写入失败必须进入 COMMIT_PENDING，不能静默报告完整闭环 |
Hook 的自然语言注入应分为三段：task_facts、failure_guidance、route_status。route_status 优先作为结构化元数据；如果当前客户端只能使用 additionalContext，也必须有明确标签和单一上限，避免 deferred guidance 与 bootstrap 内容相互覆盖。
🧰 CTX-5：工具输出与压缩策略
大工具输出的优化目标不是删除证据，而是把“结论、状态、证据引用、可复查入口”与原始正文分开：
| 输出类型 | 模型默认看到 | 原始内容处理 | 必须保留 |
|---|---|---|---|
| 命令/日志 | 状态、关键错误、计数、时间范围、摘要 | 完整输出放临时文件或已登记路径 | 路径、哈希、退出码、失败片段 |
| 配置/JSON | 字段路径、类型、数量、差异摘要 | 凭据和长值不进入模型正文 | schema、版本、哈希、敏感字段存在性 |
| 网页正文 | 与问题相关的段落和来源 | 长正文只保留路径/引用，按需回读 | URL、抓取时间、状态码、关键引用 |
| 浏览器/桌面状态 | 当前页面/窗口状态和动作结果 | 截图或完整树按需保存 | 目标、动作、后置状态、失败原因 |
| Memory 结果 | 去重后的事实摘要和来源 hash | 原始记忆保留在 Memory 服务 | 命中/未命中、冲突、版本和新鲜度 |
压缩前的最小结构化摘要固定包含：当前目标、授权范围、硬约束、已验证事实、已执行动作、证据路径/哈希、未决项、下一步和回退点。压缩摘要不能替代原始证据；模型需要细节时必须按路径回读，而不是依赖摘要继续猜测。
📚 CTX-6：Context7 文档层只读评估
本轮只检查本机资产和官方文档，不安装 Context7、不写入 config.toml、不创建 Skill、不启动新 MCP 服务。
| 项目 | 只读结论 | 证据与影响 |
|---|---|---|
| Context7 Skill | 未发现已安装 Skill | 在 /root/.codex/skills 和 /root/.agents/skills 限定范围内检索 context7、find-docs、resolve-library-id、query-docs 均无匹配 |
| Context7 MCP | 当前会话工具面未发现 Context7 命名空间 | 当前可见的是 local_search_registry 与 web_fetch；没有把通用网页工具误报成 Context7 |
| Context7 CLI | 已通过隔离 npx ctx7@0.8.2 验证，未全局安装 |
library、docs 和 JSON 输出可用；版本与安装边界见 CTX-7 证据 |
| 现有文档层 | 已有搜索与网页抓取；浏览器层可进一步读取页面 | 适合一般公开网页和页面交互，但没有证明具备库名、版本和 API 符号级文档索引 |
| 共享配置影响 | 需要特别谨慎 | 官方 Codex MCP 文档说明 MCP 配置位于 Codex 主机配置，并由桌面端、CLI 和 IDE 共享；直接新增 MCP 会影响共享配置面，不能当作单轮轻量插件 |
三种候选方案比较：
| 方案 | Token / 延迟 | 维护与部署 | 质量边界 | 当前建议 |
|---|---|---|---|---|
| 不新增 | 增量成本最低；文档任务可能多一次搜索和抓取 | 无新增维护面 | 普通网页和现有项目文档足够；库版本 API 定位较弱 | 作为当前回退和默认基线 |
| Context7 MCP | 有机会用定向结果减少无关网页正文；每次检索增加 MCP 调用和延迟 | 需要维护共享 MCP 配置、可用性、认证和工具面 | 适合库/版本/API 文档；依赖索引新鲜度和版本覆盖 | 只在独立对照会话评估，不直接全局安装 |
Context7 CLI + find-docs Skill |
Skill 可按意图选中，常驻上下文成本可能更低；CLI 启动增加单次开销 | 同时维护 CLI 依赖、Skill 版本和流程 | 可把库识别、版本选择、输出上限和引用格式写成可审阅流程 | 作为优先评估候选，但先确认 CLI/Skill 真实来源和输出契约 |
CTX-6 的阶段结论是：不纳入默认常驻层。Context7 可继续作为文档层候选；先用现有 web_fetch/搜索完成同一组固定文档任务作为基线。只有当 Context7 在版本命中、返回规模、延迟和事实准确率上有明确收益，且能保留可回退入口时，才进入隔离对照。
🧪 CTX-7：隔离对照实验（部分单次样本已运行）
CTX-7 的目的不是证明某个工具“回答看起来不错”，而是在同一任务和同一模型条件下，检查是否真的减少无关输入、是否改善文档版本命中，同时保持回答正确性。首轮只使用临时目录和独立 MCP 子进程，没有运行 ctx7 setup、全局安装 Skill/MCP 或修改 Codex 配置。
| 对照组 | 文档能力 | 用途 |
|---|---|---|
| A 基线 | 现有 local_search_registry + web_fetch |
测量当前任务成本和质量 |
| B Context7 MCP | Context7 的 resolve-library-id + query-docs |
测量专门文档检索路径的增量价值 |
| C CLI + Skill | Context7 CLI + find-docs Skill |
测量按需加载说明与命令输出的成本/收益 |
固定任务集至少包含三类：指定库和版本的 API 事实核对；从较长官方文档中回答带引用的问题；当前项目已有本地文档和外部文档存在冲突时，判断适用版本并说明依据。每个任务组使用相同的提示词、模型/Provider、工作目录、权限和目标版本；随机化执行顺序，避免缓存热度或先后顺序固定偏向某一组。每种任务至少重复 5 次；正式次数应在采样前冻结。
每次运行只记录非敏感结构化结果：输入/缓存/输出 tokens（Provider 未提供时记未知）、MCP schema 和工具输出字符数、调用次数、端到端延迟、库/版本识别是否正确、事实判断、引用是否支持结论、无依据陈述数和失败类型。不得把完整 Prompt、密钥、登录态、私人资料或原始长输出加入计划文档；必要原始证据按项目 temp/ 规则保存，只在文档记录摘要、路径和哈希。
完整单次任务集
| 任务 | A：现有网页层 | B：Context7 MCP | C：Context7 CLI | 当前能得出的结论 |
|---|---|---|---|---|
| T1：TypeScript MCP SDK 的 Streamable HTTP server | 官方页面读取成功，Web Fetch 输出设置 7,000 字符上限并被截断 | 端到端 initialize、tools/list、resolve-library-id、query-docs 成功；两个工具；定向结果约 5,064 字符；CLI 冷启动计入后全流程约 25 秒 |
library 约 5.08 秒、结果 2,830 字节；docs 约 5.14 秒、结果 7,506 字节，返回 5 个 code snippets |
MCP 自动解析到 /websites/ts_sdk_modelcontextprotocol_io_v2；CLI 手动选择到 /modelcontextprotocol/typescript-sdk。来源选择不同，需纳入质量核对 |
| T2：FastAPI BackgroundTasks 和重任务 caveat | 官方页面读取成功，首轮请求上限 7,000 字符 | 未运行 | library 约 6.41 秒、结果 2,483 字节；docs 约 6.25 秒、结果 6,708 字节，返回 4 个 code snippets、1 个 info snippet |
已证明 CLI 查询链可用；未比较 MCP 输出，也未做事实评分 |
T3：React useEffect subscription cleanup |
尚未运行 | 尚未运行 | library 约 6.38 秒、结果 2,529 字节；docs 约 6.62 秒、结果 8,908 字节，返回 3 个 code snippets、2 个 info snippets |
只有 CLI 单样本，不足以判断质量或收益 |
5 次重复矩阵
按固定任务、固定查询、固定官方目标 URL 和固定包版本运行，每格 5 次；样本顺序轮换，减少固定先后偏差。下表时间为端到端中位数。
| 任务 | 组 | 成功 | 中位延迟 | 中位输出字符 | 关键事实覆盖 | 官方来源命中 |
|---|---|---|---|---|---|---|
| T1 MCP SDK | A 网页层 | 5/5 | 2.277 s | 7,429 | 5/5 | 5/5 |
| T1 MCP SDK | B Context7 MCP | 5/5 | 7.853 s | 5,655 | 5/5 | 2/5 |
| T1 MCP SDK | C Context7 CLI | 5/5 | 11.106 s | 6,943 | 5/5 | 2/5 |
| T2 FastAPI | A 网页层 | 5/5 | 2.532 s | 7,583 | 4/5 | 5/5 |
| T2 FastAPI | B Context7 MCP | 5/5 | 6.561 s | 5,215 | 5/5 | 5/5 |
| T2 FastAPI | C Context7 CLI | 5/5 | 10.012 s | 6,213 | 5/5 | 5/5 |
| T3 React | A 网页层 | 5/5 | 2.509 s | 7,396 | 5/5 | 5/5 |
| T3 React | B Context7 MCP | 5/5 | 7.174 s | 8,414 | 5/5 | 5/5 |
| T3 React | C Context7 CLI | 5/5 | 10.294 s | 8,374 | 5/5 | 5/5 |
结论如下：
- 现有网页层仍是默认基线。它 15/15 成功，来源始终是官方页面，T1/T3 的关键事实全覆盖，热请求中位延迟约 2.3-2.5 秒。T2 的固定 7K 抓取上限稳定丢失 heavy-work/Celery 段落，只覆盖 4/5。
- Context7 MCP 是有效的定向补位。15/15 成功，T2 补回了网页层漏掉的 caveat，T1/T2 输出更小；但端到端中位延迟约为 A 的 2.8-3.5 倍，且 T1 的自动库选择在官方 GitHub 仓库与官方文档站之间 3/2 波动。
- Context7 CLI 暂不适合作默认路径。15/15 成功、事实覆盖完整，但每任务要启动两次
npx查询，中位延迟约 10-11 秒，明显慢于 MCP；CLI 的 T1 选择也和 MCP 一样出现 3/2 波动。
CLI 返回字节数、MCP/网页结果字符数不是模型输入 Token；本轮长会话中的工具结果会改变后续输入前缀，因此不报告组间 Token 差异。完整原始证据位于 /root/project/AgentMeshOS/temp/ctx7-eval-20261031/matrix-results.json，SHA-256 为 c1088f46278d93a9607f33ed26c66144f20491048a6351648572c3b2f0f90a19。CLI 使用 npx ctx7@0.8.2，MCP 使用 @upstash/context7-mcp@3.2.5 独立 stdio 子进程；CLI 包体约 360 KB、MCP 包体约 99 KB，未做全局安装。临时 MCP 探针首次错误使用 Content-Length framing 导致超时，改用行分隔 JSON-RPC 后通过；该 harness 错误不计为产品故障。
✅ CTX-8：质量、负向与回退验收
| 验收项 | 结果 | 证据与影响 |
|---|---|---|
| 正向可用性 | 45/45 隔离样本成功 | A/B/C 三组、三任务、五次重复均返回结果 |
| 关键事实 | 44/45 样本达到 4/5 以上；A-T2 固定为 4/5 | Context7 B/C 在 T2 补回 Celery/queue caveat；网页层因 7K 截断缺项 |
| 来源可追溯 | A 15/15 直接保存官方 URL；B/C 中 T2/T3 为 5/5，T1 为 2/5 | T1 的 Context7 选到官方 GitHub 仓库时，不包含目标文档站域名；来源判断必须检查 URL 语义，不只看“命中官方项目” |
| 库选择稳定性 | T1 的 B/C 均出现 3/2 分布 | 自动解析可能选仓库或文档站；版本敏感任务应显式指定库/版本 ID，或保留人工确认 |
| 无效库错误语义 | CLI 返回码 1、错误文本在 stdout 而非 JSON；MCP 返回成功且 isError=false，但没有库 ID 和文档，只返回“No libraries found”文本 |
接入层不能只看 JSON 可解析或 isError；必须同时校验退出码、选中 ID 和结果正文 |
| 回退路径 | 现有网页层 15/15 可用 | Context7 失败时可退回搜索 + web_fetch；网页被截断时应提高抓取上限或改用定向片段 |
| 运行边界 | 未修改共享 Codex 配置和 Hook | 实验结束时 codex mcp list 仍无 Context7；config.toml 与 hooks.json 修改时间早于实验开始，配置未写入 Context7 |
CTX-8 实验验收结论：可用，但不默认常驻。推荐保持现有网页层为 L2 默认入口，把 Context7 作为按需定向文档能力；若后续要实施，优先评估 MCP，而不是 CLI。实施前必须先修正两个接入风险：显式库/版本选择和错误语义解析。
质量判定采用“硬事实先过、成本再比较”：每个样本必须核对版本命中、结论事实、官方来源引用和不确定性表达；任何错误版本、关键事实错误或虚构引用都记为质量失败。只有候选组质量不低于基线、无硬事实失败，并且在重复样本中稳定降低单轮输入或端到端时间，才进入 CTX-8 的综合评估。具体最小收益阈值在真实采样前根据 A 组方差冻结，不预先编造节省比例。
本实验会涉及新增文档能力和桌面/CLI 可见性，不能从静态配置或某个工具清单推断真实行为。启动前需先确认测试载体、Context7 官方接入要求、凭据来源及隔离边界；若无法保持对照变量一致，则标记实验不可比，不以结果支持启用决策。
🔧 工作包清单
| 编号 | 工作包 | 目的 | 状态 |
|---|---|---|---|
| CTX-0 | 只读基线与指标冻结 | 记录固定前缀、schema、单轮输入、缓存、压缩、Memory 命中和工具调用 | 完成可观测基线；schema 字符已测量，固定 Token 换算不可得 |
| CTX-1 | MCP 分类与工具成本盘点 | 为每个 MCP 建立工具数、schema 成本、调用频率、权限和数据风险表 | 完成：6 个启用服务、128 个工具、逐服务字符成本与两线程调用频率已记录 |
| CTX-2 | 会话档位契约 | 比较 L0 至 L5 的候选组合、工具级筛选、配置继承和桌面实际行为 | 5 个 profile（base/docs/browser/desktop/full）已安装到 101 并复验 PASS；缺失 profile 静默回退已被 PROFILE_SILENT_FALLBACK 拦截；模型回合证据待补 |
| CTX-3 | Memory 按需召回设计 | 保留可取得性，降低无关候选、重复画像和过长注入 | 设计完成；本轮不修改当前召回参数 |
| CTX-4 | Hook 输出分层 | 评估 UserPromptSubmit 与压缩前后的信息传递，保留必要证据和可回读入口 | 设计完成；route 状态、观察积压、prompt capture 和失败类别已纳入 |
| CTX-5 | 工具输出与压缩策略 | 规定日志、配置、网页和代码输出的摘要、路径引用及保真边界 | 设计完成；本轮不修改工具输出 |
| CTX-6 | Context7 文档层评估 | 对比现有网页工具、MCP 常驻、MCP 按需及官方 CLI + find-docs Skill |
评估完成、交付未完成：CLI 与 MCP 均只在隔离环境验证；"不纳入默认常驻"是运行期策略，不等于已安装，安装归口见 CTX-9 |
| CTX-7 | 小范围对照验证 | 在固定模型、样本和权限下比较当前文档层、Context7 MCP、CLI + Skill | 完成实验：3 任务 × 3 组 × 5 次，共 45 个隔离样本 |
| CTX-8 | 质量与回退验收 | 检查事实命中、路径引用、负向样本、压缩后连续性和回退能力 | 完成本实验范围：正向、事实、来源、负向、回退和运行边界均已验收 |
| CTX-9 | 按需能力交付（Context7） | 把已证可用的 Context7 MCP 落成安装单元、档位入口和卸载回退，使其能真正被按需启用 | 完成安装：config.toml 增 [mcp_servers.context7]（enabled=false），新增 docs 档；不带 -p 仍不启用（零上下文成本），-p docs 实测启用 4 个服务；initialize+tools/list 通过（2 个工具、4,999 字符、3.1 秒） |
| CTX-10 | 按需启用策略与默认集收敛 | 为所有已安装 MCP 定"常驻 / 按需 / 删除"，并给 CLI 与桌面端各一条可验证的启用通道 | 完成并修正方向：改为"全部可用 + 工具级裁剪"，默认档实测 46,897 tokens（较全量 69,224 省 32.3%）；npx 启动缺陷已定位并修复；Memory 偶发不可用仍待处理 |
依赖顺序为 CTX-0 → CTX-1 → CTX-2 → CTX-3/CTX-4/CTX-5，Context7 评估依赖 CTX-1 和 CTX-2，最终对照验证依赖全部前置设计完成。CTX-3、CTX-4、CTX-5 可以在契约冻结后并行讨论，但不能各自形成互相冲突的注入规则。CTX-9 依赖 CTX-2 的档位机制与 CTX-8 的质量结论，是"按需能力"从验证走向可用的唯一出口。
结论分级纪律（本轮补记）：任何"不常驻/按需"的策略结论，必须同时交付三件套——安装单元（可复现命令与版本校验）、按需启用入口（档位或开关）、卸载回退步骤。三件套缺一项，工作包状态只能写"未交付"。此前 CTX-6 把"运行期不常驻"写成了"完成评估"，导致 Context7 在 45 个样本里验证可用却从未安装，这是计划设计缺陷而不是执行疏忽，防复发机制已登记为 planning.policy_conclusion_treated_as_delivery。
第二条纪律（同日补记）：用户的质疑不是安装授权。用户问"Context7 装了吗"，只说明存在疑点，不构成"应当安装"的结论；安装与否必须回到收益、成本、风险三项证据。反过来也不能因为"用户没要求"就停在空谈：评估完成即按结论执行，并把执行证据（mcp list、tools/list、回退命令）写回计划。此前把用户的一句追问直接读成"那就装上"，与把"不常驻"读成"不安装"是同一类错误的两个方向，已登记为 planning.user_mention_treated_as_authorization。
🧭 安装 / 常驻 / 默认启用：三轴模型（2026-10-31 修正）
优化不等于"不装"。三件事必须分开判断，否则会把"省 token"错做成"少能力"：
| 轴 | 含义 | 成本发生时机 |
|---|---|---|
| 安装 | 能力在目标机上是否可启动（包、命令、版本固定） | 磁盘与维护成本；未启用的服务不占用请求上下文 |
| 默认启用 | 不带 -p 启动时是否进入模型工具面 |
每次请求的 schema 与工具选择成本 |
| 档位启用 | -p <profile> 时是否进入工具面 |
仅该档位会话的请求成本 |
由此得出的判定规则：装得起不等于每次都要灌进上下文。凡是通过档位可控的能力，安装应该做；默认启用应该克制。反过来，把"不常驻"当成"不安装"，等于永久放弃该能力，这与优化目标相反。
📦 逐项安装决策（2026-10-31 复核）
下表的"结论"是评估结果，不是待办占位；每一项都写清依据、默认启用状态和回退方式。
| 对象 | 安装结论 | 默认启用 | 依据 | 回退 |
|---|---|---|---|---|
Context7 MCP @upstash/context7-mcp@3.2.5 |
已安装，默认不启用 | 否（仅 -p docs 启用） |
矩阵 B 组 15/15 成功且补回 T2 事实缺口；实测 tools/list 返回 2 个工具、定义 4,999 字符、启动 3.1 秒 |
从 config.toml 删除 [mcp_servers.context7] 段，或保留但删除 docs.config.toml |
Context7 CLI ctx7@0.8.2 |
不安装 | 否 | 与 MCP 同质量但更慢（中位 10-11 秒 vs 6.5-8.8 秒），且每任务两次 npx 冷启动；同一收益保留两条路径只会制造选择歧义 |
无需回退（未安装） |
Context7 find-docs Skill |
不创建 | 否 | 其价值依附 CLI；CLI 不装则 Skill 无执行体。若将来 CLI 路线重启，再随 CLI 一起创建 | 无需回退（未创建） |
tools/codex-context-budget 审计器 |
已入库，不挂定期任务 | 否 | 变更时由 install_profiles.py --apply 自动复验即可覆盖；无变更时定期跑只会产生噪声 |
不设定时任务即无回退面 |
| Serena 语义代码检索 | 不安装 | 否 | 从未测试，没有任何本机证据支持收益；L3 维持"待评估" | 无需回退（未安装） |
🚦 CTX-10：按需启用策略（2026-10-31 实施）
策略目标是把"每轮都要付的 schema 成本"压到最小，同时保证每个能力都能在一条命令内启动。判定依据是同一组实测数字：使用频率（本线程与 M4 对照的 function call 计数）乘以单项 schema 成本。
| 服务 | 原始定义字符 | 实测调用（当前线程 / M4） | 决策 | 暴露工具 |
|---|---|---|---|---|
agentmeshos_memory |
30,951 | 3 / 21 | 常驻，全量 | 17 |
kimi_webbridge |
9,039 | 0 / 70 | 常驻，全量 | 17 |
local_search_registry |
1,339 | 12 / 18 | 常驻，全量 | 2 |
web_fetch |
981 | 13 / 44 | 常驻，全量 | 1 |
playwright |
21,093 | 0 / 19 | 常驻 + enabled_tools 裁剪 |
13（原 25） |
cua-driver |
225,366 | 0 / 15 | 常驻 + enabled_tools 裁剪 |
12（原 66） |
context7 |
4,999 | 新增 | 常驻，node 直启 |
2 |
chrome-devtools |
— | 0 / 0，且长期 enabled=false |
删除 | 0 |
启用方式的选择依据是"用户不该为工具切换买任何操作成本"：桌面端不能传 -p，所以服务保持默认可用，靠工具级裁剪把成本压下来；codex -p base 这类极简档只在需要极限省上下文时用；switch_defaults.py --preset 保留为"确实要把某个服务彻底关掉"的运维手段。
实测结果：默认档（不切档、不重启、不改配置）单次输入 46,897 tokens，全量档 69,224，极简档 33,977。默认档比全量省 32.3%，同时 cua_driver、playwright、context7 三组工具都在同一回合里可用。
📈 优化前后实测对比（2026-10-31）
方法：固定模型 deepseek-v4.1-flash-opencode、固定提示词「只回复两个字符：OK」、-s read-only、--ephemeral，每档 3 次交错执行，避免单档连续跑带来偏差。base 代表优化后默认集，full 代表优化前全量集。原始证据：temp/compare-20261031/run-*.jsonl、timings.txt。
| 指标 | 优化后（base） | 优化前（full） | 差异 |
|---|---|---|---|
| 单次请求输入 tokens（3 次均一致） | 33,977 | 69,224 | 少 35,247（-50.9%） |
| 缓存命中 tokens（热态） | 33,920 | 69,120 | 两者缓存机制均正常 |
| 端到端耗时中位数 | 7.13 s | 8.64 s | 快约 1.5 s |
| 暴露的 MCP 工具定义字符 | 42,310 | 288,769 | -85.3% |
最终形态（全部服务默认可用 + 工具级裁剪，无需切档或重启）单次输入 46,897 tokens：比全量省 32.3%，比极简档多 12,920 tokens，换来 cua_driver/playwright/context7 三组工具随时可选。
2026-10-31 重启 Codex 后复测（同一模型、同一提示词、各 3 次）：默认档 46,992 tokens（3 次完全一致）、极简档 -p base 34,034、任务级（读 profiles.json 答 base 档服务）76,050 且答案正确。工具面实测 128 → 64 个，定义字符 288,769 → 119,514（-58.6%）。三组能力功能复验通过：Context7→/websites/fastapi_tiangolo、Playwright→Example Domain、CUA→564 个应用。
任务级对照（提示词：读取 tools/codex-mcp-profiles/profiles.json 并输出 base 档服务名，需真实调用 shell）：两档答案完全一致（4 个服务全对），base 输入 69,055 tokens，full 输入 144,706 tokens，同样正确率下少 52.3% 输入。这说明节省不是靠牺牲正确性换来的。
工具面在真实模型回合中的表现（同一模型，问「列出可用 MCP 命名空间」）：base 返回 kimi_webbridge / local_search_registry / web_fetch；desktop 返回 cua_driver / kimi_webbridge / local_search_registry / web_fetch，说明按需档确实能把重量级能力放进来。
同一轮测试暴露两个真实缺陷，其中一个已定位并修复：
| 缺陷 | 现象 | 证据 | 状态 |
|---|---|---|---|
| npx 启动的 MCP 在 Codex 里静默失效 | context7、playwright 配置启用且 mcp list 正常，但真实回合模型回答 NO_TOOL |
ctx7-call.jsonl、docs2.log |
已修复：npx -y … 换成 node <固定安装路径> 后两者都出现在默认回合里 |
| Memory MCP 在 CLI 回合偶发不可用 | Transport channel closed … memory/mcp、route-aware request timed out，同批测试里有回合能列出 memory、有回合列不出 |
ns-base.jsonl、ns-docs.jsonl |
未修复，与本轮档位改动无关，需单独定根因 |
🧰 工具级裁剪与 npx 陷阱（2026-10-31）
结论：按需的正确实现不是"关掉服务"，而是"服务常在、工具裁剪"。实测 enabled_tools 在本机 Codex 0.163.0 上真实生效：用一个只有 alpha/beta/gamma 的假 MCP 对照，不加过滤时模型看到 3 个工具，加 enabled_tools=["alpha"] 后只看到 1 个（temp/compare-20261031/fake_mcp.py）。
npx 陷阱的定位过程有决定性证据：npx -y @upstash/context7-mcp@3.2.5 在 Codex 里永不出现工具；同一包改用 node /root/.codex/mcp/context7/.../dist/index.js 立刻出现 2 个工具。因此把两个 MCP 都改为固定目录安装 + node 直启，Playwright 同样从 npx @playwright/mcp 换成 node /root/.codex/mcp/playwright/node_modules/@playwright/mcp/cli.js。
当前默认档（不带 -p、不重启、不改配置）的实际状态：cua_driver 12 个工具（从 66 裁剪）、playwright 13 个（从 25 裁剪）、context7 2 个，全部在同一个回合里可用。单次输入 tokens 实测 46,897，比全量 69,224 少 32.3%，比"手动切档的极简集" 33,977 多 12,920——这 12,920 就是"随时能用桌面/浏览器/文档工具"的代价，符合"需要就调用、不需要就不调用"的要求。
三个能力的功能验证（不依赖模型自述）：
| 能力 | 验证方式 | 结果 |
|---|---|---|
| Context7 | 协议直连 resolve-library-id(query="fastapi") |
返回 /websites/fastapi_tiangolo，1,648 字符 |
| Playwright | 协议直连 browser_navigate(https://example.com) |
页面标题 Example Domain，导航成功 |
| CUA Driver | 协议直连 list_apps() |
返回 581 个应用（497 运行中 / 84 已安装） |
补充说明：模型层直接调用 Playwright/CUA 时会被既有 PreToolUse Hook 的"网页路由阶梯"拦截（要求先 web_fetch 失败、再 web_search），这是既有规则设计，不是 MCP 故障；因此功能验证走协议直连，Hook 行为保持不变。
🧪 验收指标与验证方法
每个候选方案记录可获得的指标：固定前缀和单轮输入 tokens、缓存命中与未命中 tokens、工具 schema 总量、工具调用次数、Memory 候选数量、注入字符数与实测 token、压缩次数、压缩前后关键事实保留率、回答质量和失败原因。各 Provider 未提供的字段标为“未知”，不自行推算；比较前固定模型、任务、版本、样本和统计口径。
验收应覆盖普通问答、需要 Memory 的连续任务、需要外部文档的版本核对、需要工具输出的大型诊断任务，以及压缩后继续工作的样本。每类样本对照基线和候选方案，比较事实准确率、关键路径是否保留、工具是否仍可取得、错误是否被如实报告。Memory 至少覆盖命中、未命中、冲突、已更新和服务不可用；未命中与服务不可用不能混为一谈。不能因为 token 下降就直接判定优化成功。
最低通过条件如下：
- 先建立可复现基线，再评估固定前缀和单轮输入的变化，不预先承诺节省比例。
- Memory 需要的历史事实仍能按需检索到，且没有把长期事实误当成当前事实。
- 如选择评估 Context7，分别测试 MCP 与官方 Skill 的调用质量、返回规模、延迟、隐私和可用性。
- 大工具输出不会整段重复注入，但关键结论、证据路径和错误信息仍可复核。
- GPT 线程的压缩频率下降或至少不增加，压缩后任务连续性不劣化。
- 任一档位失败时可回到当前配置，不影响正在运行的会话和生产节点。
💾 配置、数据与分布式底座声明
本阶段不接入 AgentMeshOS 分布式底座。原因是本计划只研究本机 Codex 的上下文、MCP、Skill、Memory 和 Hook 组合，不创建 Nomad Job、Worker、Runtime API、数据库或长期业务 Artifact。
配置权威仍属于 Codex 的 CODEX_HOME；Memory 权威仍属于现有 Memory 系统；项目计划和测试证据属于本仓库 docs/plans/ 与项目 temp/。任何凭据、Token、Provider 配置和系统级 Codex 文件都不得复制进仓库。测试中如产生长日志或原始工具输出，只能放入 temp/，正文记录摘要、路径和哈希。
🔁 回退与风险
| 风险 | 影响 | 回退方式 |
|---|---|---|
| 工具层裁剪过度 | 模型无法找到必要能力 | 立即恢复当前 MCP 暴露集合，保留失败样本 |
| Memory 注入过短 | 连续任务事实命中下降 | 恢复上一版 Hook 默认值，按查询类型增加候选 |
| 工具输出过度摘要 | 证据或错误细节丢失 | 恢复该工具的完整输出模式，仅限制重复注入 |
| Profile 与桌面客户端行为不一致 | 计划档位只对 CLI 生效 | 标记为待验证，不把 CLI 结果推广到桌面 |
| Context7 限流或延迟 | 文档任务变慢或失败 | 保留 Web Fetch/官方文档路径作为回退，说明失败原因 |
| 压缩摘要错误 | 后续回答偏离原任务 | 使用 PreCompact 结构化摘要和原始文件引用，必要时回读证据 |
任何实施批次都必须保留当前配置的 last-known-good 备份。实施前先在隔离测试会话做负向回归；未完成真实验证前，不修改 101、102 或其他节点的 Codex 配置，不分发新的全局规则。
🔜 实施顺序与阶段出口
第一阶段完成 CTX-0 和 CTX-1 的可观测基线；第二阶段完成 CTX-2 至 CTX-5 设计契约；第三阶段完成 CTX-6 只读候选评估；第四阶段完成 CTX-7 隔离矩阵和 CTX-8 质量/回退验收；第五阶段才讨论是否修改本机配置。当前前四阶段已完成到实验范围，CTX-0/1 的 schema 字符成本已冻结但无法换算为固定 Token；CTX-8 的压缩连续性只能在未来实施批次中结合运行前后对照验证。
第五阶段（本机配置实施）目前只完成了工具面一半：CTX-2 的 5 个档位已装到 101 并复验 PASS，Memory 注入（CTX-3）、Hook 分层（CTX-4）、输出与压缩策略（CTX-5）仍停在设计，未改动任何 Hook。第六阶段 CTX-9 已完成安装：Context7 以 enabled=false 写入配置、由 docs 档按需启用，卸载只需删除该配置段；推广到其他节点前，先补一次 -p docs 的真实模型回合证据。
第七阶段 CTX-10 的最终形态是"全部可用 + 工具级裁剪"：默认档一次回合内即可使用 cua_driver(12)、playwright(13)、context7(2)，实测 46,897 tokens；chrome-devtools 删除；-p base 保留为极限省上下文档（33,977 tokens）。剩余风险是 Memory MCP 偶发不可用，以及 switch_defaults.py 会把默认集写成全局状态，退回落点为 <CODEX_HOME>/profile-backups/<时间戳>-config/config.toml。
阶段出口不是“token 变少”，而是同时满足资源下降、质量不降、Memory 可取、工具可用、缓存没有明显恶化、压缩连续性可接受和完整回退可执行。任何一项证据不足，都保持“待验证”，不进入全局分发。
⚠️ 未决项 / 需要用户决策
| 事项 | 当前状态 | 建议 |
|---|---|---|
基础档是否保留 web_fetch |
建议保留 | 15/15 成功、来源稳定且中位延迟最低；长页面需要提高上限或按段读取 |
| Context7 接入形式 | 实验完成 | 不作为默认常驻；若实施，优先按需 MCP，并强制显式库/版本 ID、校验选中 ID 和错误文本 |
| Context7 API Key | 当前不需要 | 匿名 CLI/MCP 查询已通过；只有触发限流或需要更高配额时再评估，凭据不得进入仓库或 Memory |
| CUA / Playwright 工具面 | 建议优先优化 | CUA 有 66 个工具、225,366 定义字符，占全部定义面约 78%；应只在桌面任务启用，不进入普通基础档 |
| Serena 是否安装 | 待决策 | 仅在大型代码分析收益明确后评估，不作为基础层 |
| 浏览器层如何组合 | 待评估 | 比较真实登录态和自动化场景，允许按需组合，不预设只能二选一 |
| 是否启用 Codex 开发中 tool-search flag | 不建议现在决定 | 等稳定性和桌面端支持证据，当前不作为基础方案 |
| 是否进入实际配置实施 | 已在 101 安装 profile 文件（可逆） | 删除 5 个 <name>.config.toml 即回退；模型回合与桌面端证据待补 |