# AI 助手运行底座重评：结论、证据与汇报提纲（草案）

> 性质：**工作层调研与汇报准备件**，不是对外稿，不改既定口径。发起：白晨 2026-09-21 口述（要说服陈洁（Ricky，部门研发负责人）同意「平台 AI 助手不跑在 ndclaw 运行时上、改用轻量 harness」）。本文先判断主张是否成立，再给证据，最后给汇报提纲；**向上汇报稿另写**，等白晨与本文对齐后再出。
> 取证日期 2026-09-21。四份附录各自独立取证：[附录 A](附录A-ndclaw运行时成本与延迟考古.md) 是 `~/AI-Hub-Project/` 只读代码考古＋AWS 中国区官网定价；[附录 B](附录B-进程内薄harness候选调研.md) 是 Python 进程内薄 harness 候选的一手取证；[附录 C](附录C-业界证据-沙箱必要性首响与成本.md) 是四家厂商官方口径、定价、首响研究与同类产品；[附录 D](附录D-Codex独立评审-扮演陈洁质询与独立判断.md) 是 Codex 经 orca 独立写的对抗评审（扮演陈洁的 12 条质询＋独立判断＋最小实验）。
> 标注：【事实】有一手来源；【推断】基于事实的推理；【待验证】需实测或问人。仓库内引用写 `路径:行号`。

## 零、一页结论

1. **白晨的方向成立，但三条主张要各自修正一处，否则在陈洁面前站不住。**
   - 「定位不需要沙箱」：**成立**，且不是新主张——对外技术方案 §3 已定 AI 助手是「组织者，自己不产出内容」，0902 的 36 页已建议「团团平台自建、AI 员工经 A2A 接 ndclaw」。要补的是「首期工具白名单里没有代码执行、浏览器、任意上传件解析」这个前提（附录 D 第 8 条）。
   - 「冷启动差」：**成立且有一手证据**（daemon README 实测：冷路径点击到第一个字约 60 s、预热池约 25 s、第二轮起 3～7 s；18 s 首轮 TTFT 来自 OpenClaw 进程内懒初始化，预热池帮不上）。要补的是：这组数字是 OpenClaw 引擎的历史记录，claude-code 引擎**没有数据**——陈洁可以问「你是不是拿错了被告」（附录 D 第 4 条）。
   - 「贵，人均 100 元／月」：**不成立，要换论点**。按 AWS 中国区单价，100 个月活、每人每天 3 次短对话的容器可变成本只有 ¥300～¥1,500／月（人均 ¥3～¥15）；口述的「1 万元／月」按仓库里的 CDK 定义反推，大头是**固定设施 × 五套环境**（单环境固定部分约 ¥1,900～¥2,300，其中接口型 VPC Endpoint 就 ¥1,134）。站得住的论点是**成本形状**：短对话为 30 分钟空闲回收买单（一次 5 分钟对话计费约 36 分钟，86% 在空转）、1 分钟起计、浏览器标签页不关容器永不空闲、200 任务硬上限（附录 A）。
2. **「选 Pi」要改口为「Python 进程内（或无凭据常驻）薄 harness，Pi 只是设计参考」。** 后端是 Python，Pi 是 TypeScript 且无官方 Python 实现；Pi 不内置 MCP 这条在「工具＝进程内 Python 函数」前提下变成无关，但反过来要对技术方案 §3.3「工具面走开放工具协议」做一次显式裁决。附录 B 按新前提重打分：**pydantic-ai 4.45 第一、自建薄（借 Pi 设计）4.33 第二**，两者差在噪声内、取舍由「愿不愿用第三方抽象换一两千行自维护代码」这条组织判断定；Claude Agent SDK、DeepSeek Harness、Anthropic `tool_runner` 因「要拉子进程」或「走不了公司 OpenAI 兼容网关」不过硬门槛。详见 §四。
3. **与 0904 调研（50 页）的关系要如实讲**：那页的结论「沿用 daemon＋Claude Agent SDK 4.45 分」建立在「运行环境层＝daemon」的前提上，**没有把成本与首响作为打分维度**；它预留的唯一翻盘出口「daemon 不可复用」指的是组织条件。这次不是那个出口被触发，而是**补充了当时遗漏的两条约束（C 端首响、短会话成本形状）后的重评**。汇报时不能说「旧结论早已覆盖」，要说「按旧文预留的复核路径启动，并补上遗漏的约束」（附录 D 第 11 条与第二部分第 4 节）。
4. **业界一手证据一边倒**：OpenAI／Anthropic／AWS／Google 四家的参考架构里，沙箱都是 agent 按需调用的**工具**或长任务专用环境，不是助手本身的宿主；Anthropic 把 harness 从容器里拿出来后 p50 TTFT 降约 60%、p95 降超 90%；NN/g 的 10 秒注意力阈值放了 46 年没变，25～60 s 首响是它的 2.5～6 倍、是国产模型自身 TTFT 的 10～20 倍（附录 C）。反证（要跑代码、产文件、长时有状态的场景确实需要沙箱）真实存在，但技术方案 §4.1 已把它切到「资产通道／能力通道」，与 AI 助手「不共用同一个会话、同一份工具权限」（`docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:455`）。
5. **最该先做的一件事不是写汇报稿，是一天的对照实验**：同一网关、同一模型、同一请求，对比「当前可复用的 daemon 引擎路径」与「常驻 Python 最小流式转发路径」的新会话首响，配对 ≥ 20 组（附录 D 第二部分第 5 节给了完整步骤与判据）。它把最大的不确定性（claude-code 引擎路径到底慢不慢）变成数据，也是陈洁最难反驳的东西。
6. **两处要在汇报前收口的内部张力**：(a) 正式设计稿《工作台策划说明》写「AI 执行：优先在会话中直接完成」，与技术方案「生产类内容不由 AI 助手产出」要对齐；(b) 技术方案 §3.1／§8.1 把「每会话独立的进程或容器、预热、跨主机会话恢复」写进运行环境层定义，是以 daemon 为前提的措辞，改方案要同步改写（附录 C 第 5.3 节）。
7. **陈洁最可能的 12 条反驳已由 Codex 预演**（附录 D 第一部分），每条都写了「白晨要用什么证据才站得住」。其中三条本文还没有证据、必须问运维或实测：按环境／服务拆分的真实账单、各环境 `spare` 实际值与池命中率、claude-code 引擎首响。

## 一、AI 助手的定位：它是「组织者」，不是「个人助手」

这一节回答「平台的 AI 助手是什么」，全部依据仓库里已定的口径，不是本文新立。

| 出处 | 定位原话 | 对运行底座的含义 |
|---|---|---|
| 对外技术方案术语表（`docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:15`） | AI 助手是「用户在平台上的对话入口，是工作链的**组织者**；经工具读写业务模块，**自己不产出内容**」 | 它的工作是判断与调度，不是执行与生产 |
| 同文 §3（`:181`、`:241`） | 「对话立项、项目推进、有边界的通用问答」；「凡它能做的事，用户在界面上点击也能做」 | 它调用的是与界面相同的模块接口，工具面是平台自己的函数 |
| 同文 §3.5（`:391`、`:398`） | 「生产类内容不直接由 AI 助手产出」；「只承担让用户会用平台、聊得下去的轻问答，凡是需要产出内容或做专业判断的事一律转出去」 | 不需要文件系统、不需要执行代码、不需要跑外部技能 |
| 正式设计稿《工作台策划说明》第三节（`docs/prototypes/2026-09-16-AI创业平台设计稿正式版-开发交接/原始交付/工作台策划说明.md:56-68`） | 「交给团团：统一意图入口」——判断五类意图（讨论咨询／AI 执行／日程提醒／项目创建／查询导航），「必须反馈『我理解你是想……』」，涉及发送、提交、发布、付费、删除等动作「必须先获得用户确认」 | 每轮是「理解→复述→建议下一步→等确认」，典型的判断型短轮次对话 |
| 0903 评审裁决（[08 页](../../../wiki/08-技术方案评审与待决策裁决-0903凌晨对谈.md) 第二节） | 「资产＋运行时＝能力」：能力的运行时不放在本平台；只给 skill 不给运行时的按资产处理 | 需要沙箱的事（代跑外部技能）在**能力接入层的资产通道**，与 AI 助手是两个问题（技术方案 `:455`） |

**结论**：平台 AI 助手的本质是「理解需求→拆解任务→匹配能力→请求确认」的**判断型组织者**。ndclaw 的运行时是为「一个人×一个会话×一个可执行任意工具的沙箱」设计的个人助手底座（[36 页 §2](../../../archive/wiki过时页/wiki-过时页-0908归档/36-ndclaw复用可行性调研.md)）。两者的诉求不同，不是谁好谁坏。**「不需要沙箱」的准确说法是「首期不配置每会话通用代码执行沙箱」**——身份、数据、凭据、配额、工具权限与故障隔离一条都不少（附录 D 第二部分第 3 节有「哪些未来需求会把沙箱带回来、放在哪」的表）。

**一处要在设计稿上收口的张力**：策划说明第 62 行写「AI 执行：优先在会话中直接完成」，而技术方案定「生产类内容不由 AI 助手产出」。本文按技术方案口径理解「会话内直接完成」为轻量判断类回答（草拟、总结、提取），凡需产出作品的仍转 AI 员工；这条需在向上汇报前与产品侧对齐，否则「不需要沙箱」的前提会被这句话反问。

## 二、ndclaw 运行时的延迟与成本：证据与正确的论点（附录 A）

### 2.1 延迟【事实】

daemon README「冷启动延迟优化」节（`~/AI-Hub-Project/agent-hub-daemon/README.md:548-568`）：

| 路径 | 用户拿到 wsUrl | 首轮 TTFT | 点击→第一个字 | 第二轮起 |
|---|---|---|---|---|
| 冷（`started`） | ~42 s | ~18 s | **~60 s** | 3～7 s |
| 预热池（`claimed`） | ~6 s | ~18 s | **~25 s** | 3～7 s |

18 s 的首轮 TTFT 来自 OpenClaw 进程内懒初始化（acpx runtime、bedrock 探测在中国区必失败要等超时、插件注册）＋ Ark 首 token ~5.5 s；README 明说「warm pool 也帮不了」，「claim 后先跑一次假对话」已试过并回退。A2A 路径专家冷启动首次调用约 200 s。**claude-code 引擎没有单独的延迟数据**（只有健康检查 `start_period` 90 s 对 300 s 这一旁证）。

### 2.2 成本【事实＋推断】

- 【事实】部署在 AWS 宁夏区；OpenClaw 引擎容器 1 vCPU／2 GiB（¥0.26／h，常驻 ¥187／月），claude-code 引擎 2 vCPU／4 GiB（¥0.52／h）；预热池容器按全价空转；Router 每 60 s 扫描、1800 s 无帧回收；**上游到浏览器的任何帧都刷新活跃时间**，OpenClaw 网关每 30 s 广播 `tick`【推断，待抓帧】→ 标签页不关容器永不空闲。
- 【推断】一次「聊 5 分钟就走」计费约 36 分钟，有效利用率 14%，单次 ¥0.16（1／2 规格）。100 月活、每人每天 3 次短对话：可变成本 **¥300～¥1,500／月，人均 ¥3～¥15**。
- 【推断】单环境固定部分 ¥1,900～¥2,300／月（接口型 Endpoint ¥1,134、NAT ¥266、ALB ¥115、Router／LLM Proxy／watcher 常驻容器）；daemon 有五套环境，固定部分合计 ¥4,100～¥9,700，**「约 1 万元／月」的大头是固定设施 × 环境数，不是 80 个用户的容器时长**。仓库里没有账单、容量或月活数据可印证【待验证：问运维要按环境／服务拆分的账单】。

### 2.3 正确的论点

「人均 100 元」这个除法在方向上不成立，陈洁一句「多接 10 个用户边际成本≈0」就能打掉。站得住的是**形状**：
1. 容器费按墙钟计、含拉镜像与空闲等待；token 费按工作量计，用户不说话为零。C 端「大量短对话、长时间无人」与前者不匹配。
2. 要把 daemon 改成适合短对话，只有三类改动：缩短空闲回收、扩大预热池、共享常驻容器。前两类不改变成本形状与 18 s 首轮下限，第三类等于放弃「每会话一沙箱」——而这正是 daemon 的全部设计理由（EFS 按会话隔离、STS 作用域凭据、POSIX uid 隔离、单用户 OpenClaw 配置）。
3. 模型延迟（Ark 首 token ~5.5 s）两条路都一样，不应算在 daemon 头上；模型 token 费两条路也完全相同（都经公司 AI Gateway）。**用轻量模型时容器小时费与 token 费同量级**（GLM-5.3-Flash 一次 15 轮会话约 ¥0.12 对一小时容器 ¥0.14），技术方案 `:431` 引用的「token 花费比宿主高一个数量级」只在旗舰价位成立，汇报时不要引它。

## 三、业界怎么做（附录 C）

| 厂商 | 官方口径 | 出处 |
|---|---|---|
| OpenAI | Agents API 执行环境「hosted sandbox, self-hosted sandbox, or **no sandbox**」；Agents SDK 的 `FunctionTool` 是进程内函数，Code Interpreter 是单独计费的 container 工具（20 分钟一档） | 附录 C S1～S5 |
| Anthropic | Managed Agents 定位「分钟到小时级、要读写文件与跑代码」；工程博客：把 harness 从容器里拿出来、只在需要时拉容器后 **p50 TTFT 降约 60%、p95 降超 90%**；《Building effective agents》「最成功的实现用简单可组合的模式而不是复杂框架」 | S6、S7、S9 |
| AWS | AgentCore Runtime（每会话 microVM）与 Code Interpreter 是两个独立计费产品；冷启动均值 2.9 s、预热后 250 ms | S10～S12 |
| Google | ADK 官方部署路径之一是 Cloud Run 上的普通 FastAPI 容器、多会话共用、会话存数据库；Code Execution 另作沙箱产品 | S13～S16 |

首响预期：NN/g 0.1 s／1 s／**10 s** 三阈值（超过 10 s 用户注意力离开任务）；Artificial Analysis 实测国产模型 TTFT 1.2～2.9 s；CHI 2026 与 Andes 两项研究把首字延迟列为用户挫败与可信度的首要信号。同类「理解需求→匹配供给」产品能找到一手技术描述的两家（Upwork Uma、阿里云智能导购参考架构）都是「模型＋平台工具调用循环」，无每用户常驻沙箱。

## 四、候选：Python 进程内薄 harness（附录 B）

**硬门槛两条**：①能在平台 FastAPI 进程内以库方式运行、不拉子进程；②能经公司 OpenAI 兼容网关调含 GLM 的模型。三个候选被门槛淘汰，原因都是「不是进程内」或「走不了公司网关」，不是能力问题：Claude Agent SDK 唯一传输是拉起捆绑在 wheel 里的 `claude` CLI 子进程（二进制 217 MB），官方明说不支持经网关路由到非 Claude 模型；DeepSeek Harness 官方 Python SDK 是「用 JSON-RPC 驱动 `dsh` 子进程」，架构文档明确拒绝进程内挂载，今天仍标 developer preview；Anthropic SDK 的 `tool_runner` 请求路径硬编码 Anthropic Messages 协议，且只能调 Claude。

**打分**（八维：50 页六维保留但 E「协议跟进」从 15% 降到 5%、A／B 各降 5%，新增 G「首响延迟」与 H「常驻成本」各 10%）：

| 候选 | 总分 | 门槛 | 一句话 |
|---|---|---|---|
| **pydantic-ai**（`pydantic-ai-slim[openai]`） | **4.45** | 过 | 纯 Python、核心依赖 9 个、确认门完全本地（`requires_approval` → `DeferredToolRequests` 落库 → `DeferredToolResults` 续跑）、已有智谱 GLM 的 provider 与 profile、版本政策明文「minor 不做破坏性变更」（2.0 于 2026-06-23 发布）、遥测 opt-in |
| **自建薄（Python，借 Pi 的 loop 设计）** | **4.33** | 过 | 可移植与不被收割两维满分；新前提把 50 页「要自己重写的六项」砍掉三项（子 agent、技能加载、会话分支）、两项降级（压缩→按轮截断、多模型差异→网关抹平只剩 GLM 的 strict／json_schema），剩 loop＋事件＋钩子＋序列化约 1～2 千行加同等测试 |
| OpenAI Agents SDK | 4.05 | 过 | MIT、进程内；但 `0.Y` 每升即 breaking（6 个月 6 次）、强依赖 `mcp`、默认往 OpenAI 上报 tracing 要关、Chat Completions 路径静默丢字段 |
| Google ADK | 3.80 | 过 | Apache-2.0；核心必装 23 项含 fastapi／uvicorn／otel 与平台叠一层；双向流仅 Gemini；Event 模型是 Gemini 形态 |
| Pi（Node sidecar） | 3.15 | 不过① | 无官方 Python；agent 包 6 个月 9 个版本带 Breaking Changes，无 semver 承诺；core 的 `runLoop` 只有约 130 行、但 core 包不含测试 3 万行，「loop 薄」成立、「包薄」不成立 |
| Anthropic `tool_runner`／DeepSeek Harness／Claude Agent SDK | 3.45／2.95／2.90 | 不过 | 见上 |

**读法**：pydantic-ai 与自建薄差 0.12 在噪声内，敏感性分析显示两者取舍**不由分数定，由一条组织判断定**——平台愿不愿意用一个第三方的 `Model`／`Agent` 抽象换掉一两千行自维护代码。附录 B 的建议：先用 pydantic-ai 起步，把**工具函数、消息历史 JSON、确认门协议**三样写成平台自持的边界，两年内若要换成自建，业务面零改动。**Pi 的正确位置是设计参考**：值得搬到 Python 的是它 loop 的形状（10 种三层事件、阻断／覆盖／停止三种钩子语义、steering 与 follow-up 两个队列、`stopReason=length` 时整批工具调用判失败不执行、`convertToLlm` 与 `transformContext` 两个纯函数边界），不是代码。

**与 50 页结论差异的原因是前提变化，不是事实变化**：0904 到 0921 被核实的事实没有一条反转；变的是四条前提（运行环境层不再是 daemon、工具面不再以 MCP 为硬约束、确认门等由平台自建、新增首响与常驻两维），而 50 页 §6 改选条件 2 与 4 早已写明这两种前提变化下 Pi 与自建薄会升。50 页当年没评 pydantic-ai（只一句「层次更薄、未入打分表」），是本轮补进来后它拿了第一，**这一点要如实讲**。

**所有候选的首响都是路径分析，没有一个实测过**——这是 §零第 5 条实验要补的进程内那一半。

## 五、Codex 对抗评审要点（附录 D）

Codex 扮演陈洁给了 12 条质询，本文认为**最要命的四条**是：

| 质询 | 本文能否回应 | 缺什么 |
|---|---|---|
| 「你测的是 OpenClaw，9 月 4 日推荐的是 claude-code 引擎，是不是拿错了被告？」 | 部分：README 只有 OpenClaw 数据 | **claude-code 引擎首响实测**（§零第 5 条的一天实验） |
| 「你自己 9 月 4 日给在位方案 4.45 分，现在是不是为了换方案重调权重？」 | 能：旧文没有成本与首响维度，且自己写明结论的条件性 | 措辞要是「补充遗漏约束后的重评」，不是「旧出口早已覆盖」 |
| 「不隔离进程，模型被诱导越权时业务后端的数据库凭据不就暴露了？」 | 部分：技术方案 §3.2 要求「引擎进程不持有凭据」，把引擎直接嵌进持有数据库凭据的 FastAPI 进程**不能原样满足这条** | 要显式裁决：同进程（放宽为逻辑隔离）还是「无业务凭据的常驻引擎服务＋受控工具服务」；后者仍不要求每会话一容器 |
| 「预热池加大、池内提前初始化，延迟不就解决了？」 | 能：README 记录假对话方案净时间不变、池内初始化因安全风险未做 | 要问运维当前 `spare`、池命中率、引擎版本，不能拿历史 README 当线上指标 |

Codex 的独立判断与本文一致的部分：方向对；「选 Pi」应改口；「不需要沙箱」要改成「首期不配置每会话通用执行沙箱」并列出未来触发表；先做一天实验再谈替换。**不一致的部分**：Codex 认为「daemon 优化并复用」应保留为首期路线之一直到实测证否，本文认为即使 claude-code 引擎首响达标，成本形状与前端绑定 OpenClaw／daemon 私有协议两条仍成立——这一分歧留给白晨定。

## 六、向上汇报提纲（草案，待与白晨对齐）

顺序按「先定位、再约束、再旧结论的条件、再新证据、最后只要一个小决定」：

1. **平台 AI 助手是什么**（1 页）：组织者，不产出内容，五类意图，每轮等确认。引技术方案与正式设计稿原话，不引本文。
2. **ndclaw 继续承担什么**（半页）：AI 员工经 A2A 接入，资产通道代跑外部技能——**生产能力接入 ndclaw 的方向不变**。这一页放在前面，是为了让陈洁听到「不是抛弃 ndclaw」。
3. **助手服务的三条约束**（1 页）：C 端首响目标（建议 ≤ 3 s 首字，由产品侧确认）、成本随对话量而非墙钟增长、前端不绑私有协议。附 NN/g 阈值与四家厂商参考架构一句话。
4. **0904 调研说了什么、没说什么**（半页）：4.45 分的前提与两个遗漏维度；「团团自建」与「复用运行设施」本来就在不同层。
5. **ndclaw 运行时在这三条约束下的数据**（1 页）：延迟表、成本形状、三类改法及其代价（第三类＝放弃沙箱）。
6. **候选与推荐**（1 页）：附录 B 的矩阵收成一张表，推荐＋第二选择＋Pi 作设计参考。
7. **只要一个决定**（半页）：批准一天对照实验＋向运维索取账单与池配置；实验后再决定「继续优化复用」还是「进入薄层实施评估」。不在这次会上要「抛弃 ndclaw」的批准。

## 七、待白晨定的分岔

| # | 分岔 | 选项 | 本文倾向 |
|---|---|---|---|
| 1 | 引擎放哪 | A 同 FastAPI 进程（凭据边界改为逻辑隔离，需修技术方案 §3.2／§8.1）；B 无业务凭据的常驻引擎服务＋受控工具服务（多一跳，守住原条文） | B，理由是不用改安全条文、且仍零沙箱 |
| 2 | 工具面协议 | A 进程内 Python 函数（放弃 §3.3「开放工具协议」措辞）；B 函数外再包一层开放协议适配器 | A 先做，契约（类型化参数、调用身份、幂等键、确认版本）不省 |
| 3 | 与陈洁谈的落点 | A 要「换底座」的批准；B 要「一天实验＋账单」的批准 | B |
| 4 | 设计稿「AI 执行在会话内完成」 | A 收窄为判断类回答；B 保留并承认部分产出在助手内 | A，否则「不需要沙箱」前提松动 |
| 5 | Codex 与本文的分歧：claude-code 引擎若首响达标是否仍换 | A 仍换（成本形状＋协议绑定）；B 不换 | A，但要等实验数据再说 |

## 八、本轮没做、不冒称做了的事

- 没有跑任何实测（首响、抓 `tick` 帧、账单）；所有延迟数字是 daemon README 的历史记录。
- 没有改技术方案、`sources/`、`~/AI-Hub-Project/` 与应用代码；没有提交推送。
- AWS 中国区定价只有官网一个一手来源（中英文页数值一致），第二独立来源因搜索配额耗尽未取得。
- 陈洁本人没有发言；附录 D 第一部分是模拟质询。