feat(pi): 收口 harness 能力装配、工具上下文与性能效率

## 使用场景 / Use case

PR #1718 已为 Cindy 托管的 Pi harness 接通离线 `grep/find/ls`，并避免主 Pi 的工具白名单误删动态 MCP / subagent。基础代码检索闭环恢复后，Pi 在 Cindy 中的整体性能效率仍未稳定优于 Codex，且部分 Pi 原生能力、Cindy 能力和运行时配置之间仍有断层。

需要一个 umbrella issue 统一记录已确认问题、不可突破的安全边界，以及后续可拆分为多个 PR 的实施路线。

## 已确认基线

- #1718 已解决：
- 使用 Cindy 校验并托管的私有 `rg` 提供 `grep/find/ls`
- 主 Pi 不使用会过滤动态工具的 `--tools` allowlist
- 保留动态 MCP 与 Cindy subagent
- 接通 MCP approval policy 与挂起权限请求的收口
- `PI_OFFLINE=1` 本身只应关闭 Pi 启动期版本检查、包更新/安装和相关遥测；不应关闭 provider 请求、已安装本地技能或宿主显式注册的工具。本 Issue 不建议通过关闭 offline 模式解决能力问题。
- 当前本机可用 Pi 历史任务都早于 #1718 合并，因此尚无合并后的同任务 benchmark；下文工具数量与耗时数据仅作为诊断基线，不作为最终性能结论。

## 当前问题 / Current limitations

### P0：运行时能力装配、配置发现与项目 trust 不一致

Pi 每个会话使用新的 `PI_CODING_AGENT_DIR=pi-agent-home/run-tmp/`，目前主要写入 `models.json`、Cindy bridge 与 Cindy subagent extension。

需要继续核对并收口：

- 用户级 `~/.pi/agent/settings.json`、Pi-native skills 与项目级 `.pi/.agents` 资源实际是否进入运行时
- RPC 模式不能弹 Pi 自带 project trust prompt，且临时 config home 不持久化 trust decision；没有 Cindy trust 映射时，项目资源可能被忽略
- customization scanner / 设置界面显示的资源与 Pi runtime 实际加载结果可能不一致
- 缺少“已发现 / 已批准 / 已装配 / 加载失败”的可见诊断与 capability manifest

安全边界：

- 只允许 Cindy 已批准的项目 trust 决定映射，不得无条件传 `--approve`
- 不得通过复用整个用户 Pi 目录泄露 auth、provider 配置或凭证
- #1705 已确认通用 extensions/packages 在非 TUI 宿主下存在呈现契约缺失和完整系统权限风险，并被关闭为暂不实施。本 Issue **不无条件重开 #1705**；skills、project trust 与运行时诊断可以独立推进，extensions/packages 必须等待明确的非 TUI 能力契约、显式 opt-in 和安全模型

### P0：工具 schema 常驻过多，抵消 Pi 的极简优势

Pi 上游默认核心工具只有 `read/write/edit/bash`。Cindy 历史日志样本中，一个 Pi 会话连接约 43 个 MCP 工具，再加当前本地工具后约 51 个 schema；其中 Orca 一组约 16 个。

即使模型不调用这些能力，常驻 schema 仍会增加：

- 首轮输入与 prompt cache 负担
- 模型工具选择难度
- 长会话历史和 compaction 压力
- 低频工具对高频代码任务的干扰

需要设计按任务/能力 slot 的渐进暴露：

- 默认保留代码核心工具与少量能力发现入口
- Orca、社交平台、通讯录等低频工具按用户意图或显式动作加载
- 能力仍应可发现，不应通过永久删除工具换取 benchmark
- 动态加载需要兼顾 provider prompt-cache 前缀稳定性

### P1：OpenAI / ChatGPT 未使用 Pi 原生 Responses transport

当前 Cindy/Gateway 内置 Pi provider 统一导出为 `anthropic-messages`，ChatGPT/OpenAI 请求经过本地兼容层完成 Anthropic Messages ↔ OpenAI Responses 转换。

该路径不一定增加网络 hop，但会带来协议双向转换，并可能无法完整利用 Pi/OpenAI Responses 的原生工具、推理、缓存或 compaction 语义。Pi 本身支持 `openai-responses`，需要在保持 Gateway、xAI、BYOM 兼容的前提下做同模型 A/B，而不是全 provider 一刀切。

### P1：缺少性能分段观测和可复现实验

目前无法可靠区分耗时来自：

- Pi binary spawn / RPC ready
- skills/extensions/config discovery
- 各 MCP server init / list tools
- provider 首字节与首个模型 delta
- tool round-trip
- retry / provider stall
- compaction 与超长会话恢复

需要在改变工具面和 transport 前后使用同一模型、provider、workdir 与固定任务集对比，记录至少：

- spawn-to-ready、MCP-ready
- initial prompt / tool-schema tokens
- provider TTFT、首个 tool、首段可见输出
- 每类 tool latency 与调用次数
- 完整轮次耗时、retry、compaction

### P1：高价值能力入口不够直接

- Web search / browser 目前主要依赖 plugin ghost 或通用 gateway；相比 Codex 的直接入口，模型发现和正确调用成本更高
- 可以复用 Cindy 已批准的插件能力或受管 skill，但应提供清晰、渐进式的 search/fetch/browser 能力入口
- 不应为了补搜索能力默认安装联网第三方 Pi package

### P2：其余 harness parity 缺口

- Pi extension 的结构化 Ask User / questionnaire 尚未完整映射到 Cindy UI，无法交互的 extension UI 可能被取消
- Cindy Pi subagent 目前是只读 `read/grep/find/ls` 且无 MCP；这符合上游安全默认，但主 Pi 必须串行承担所有写入/执行，可评估显式授权的执行型 profile
- `remoteHostId` 对 Pi 仍不支持
- 当前 Pi binary 不可用时不回退到已验证的缓存旧版本；这是离线可用性问题，不是单轮性能问题
- 外部 MCP 兼容面仍应核对 legacy SSE 等非当前主路径

## 建议拆分 / Suggested PR series

1. **PR 0 — 基线与观测**
增加 Pi 启动、MCP、provider TTFT、tool latency、retry/compaction 的分段指标，并建立 #1718 后的固定任务 benchmark。

2. **PR 1 — Runtime capability manifest 与 trust 对齐**
明确 scanner、Cindy approval、Pi runtime 的资源状态；接通安全的 project trust / skills 装配与失败诊断。不包含通用第三方 extension/package 执行。

3. **PR 2 — Tool surface routing**
收敛默认工具集；将 Orca 和低频 MCP 家族改为按需/渐进发现，并验证 prompt cache 与工具可发现性。

4. **PR 3 — Native Responses path**
为满足 capability 的 OpenAI/ChatGPT 路径使用 Pi 原生 `openai-responses`，保留其他 provider 的协议选择和安全降级。

5. **PR 4 — Search / browser parity**
通过 Cindy 已批准的插件或受管能力提供一等、渐进式 web search/fetch/browser 入口。

6. **PR 5+ — 交互与执行 parity**
分别评估 Ask User bridge、受限执行型 subagent、remote session、offline binary fallback 和额外 MCP transport；不要合成一个高风险大 PR。

## 验收原则 / Acceptance principles

- 保留 `PI_OFFLINE=1`，不恢复启动期自动联网安装/更新
- 不绕过 Cindy permission gate、project trust、secret-env 剥离和 MCP approval
- 不把“工具少”实现成能力永久不可达
- 不把 #1705 已否决的通用第三方 extension/package 加载夹带进低风险 PR
- 所有性能结论使用 #1718 之后、同模型同 provider 的可复现实验
- 每个 PR 独立可回滚，并在本 Issue 维护 checklist、benchmark 与关联关系

## 关联

- #1718 — 离线 `grep/find/ls` 与动态工具保留
- #1705 — 用户 Pi extensions/packages；因非 TUI 呈现契约和安全边界暂不实施
- #1265 — Pi harness、权限与 MCP bridge 基线

Start with PR #1718 and the runtime paths named here: PI_CODING_AGENT_DIR=pi-agent-home/run-tmp/, models.json, ~/.pi/agent/settings.json, and project .pi/.agents resources. First map how RPC startup, trust, skills, MCP tools, and provider transport are assembled; this umbrella is done only when its benchmark, capability manifest, security boundaries, and independently scoped PR checklist are established.

Written by the indexing model from the issue text.