历史选型调研 / 周报附件

运行底座附录 C：业界证据

历史版本 6c911d40

来源：docs/reports/2026-09-21-AI助手运行底座重评/附录C-业界证据-沙箱必要性首响与成本.md

附录 C　业界证据：沙箱必要性、首响预期与运行时成本

服务于《AI 助手运行底座重评》主文。回答一个问题：「组织者型 C 端 AI 助手不该跑在每会话一沙箱容器的 agent 运行时上」这一判断，业界一手来源支不支持？ 同时主动找反证。全部来源为厂商官方文档／定价页／工程博客、论文或标准机构页面，访问日期统一为 2026-09-21；本机仓库事实标 路径:行号。标注约定：【事实】来源原文可查；【推断】由事实按公开单价推算，假设写明；【待验证】需实测或找更多来源。

一页结论

【事实】四家主流厂商的参考架构里，「沙箱」都是 agent 按需调用的一个工具或一种可选环境，不是助手本身的宿主。OpenAI 官方把三种运行时并列，其中 Agents API 的执行环境明写「hosted sandbox、self-hosted sandbox 或 no sandbox」，Agents SDK 的 FunctionTool 就是进程内 Python 函数，Code Interpreter 是独立计费的 container 工具；Anthropic 把 Managed Agents 定位为「分钟到小时级、要读写文件与跑代码」的长任务，且工程博客明确说把 harness 从容器里拿出来、只在需要时才拉容器后 p50 TTFT 降约 60%、p95 降超 90%；AWS AgentCore 把 Runtime（每会话一 microVM）与 Code Interpreter 分成两个产品分别计费；Google ADK 的官方部署路径之一就是 Cloud Run 上的普通 FastAPI 容器、多会话共用、会话存数据库，Code Execution 另作一个沙箱产品。
【事实】每会话容器运行时的公开单价在 $0.02～$0.17／会话小时（Fargate ARM 0.5 vCPU＋1 GB 约 $0.02；AgentCore v1 约 $0.10；Google Agent Runtime 约 $0.094；E2B 默认规格约 $0.17；Modal Sandbox 1 核约 $0.17；Anthropic Managed Agents $0.08 仅计 running；OpenAI container $0.09）。这些计费的共同形状是：按墙钟时间计、含空闲期（Fargate 从拉镜像计到任务停止；AgentCore 空闲期仍计内存；OpenAI container 20 分钟一档），而模型 token 按工作量计。
【推断】按公司网关走国产模型，一次 15 轮、每轮 8k 输入／600 输出的组织者会话，GLM-5.3-Flash 约 ¥0.12、DeepSeek Flash 约 $0.02～0.05、GLM-5.3 旗舰约 ¥1.2。用轻量模型时容器小时费与 token 费同量级，Anthropic 文档「token 高一个量级」的结论只在旗舰价位成立。所以成本论点的硬核不是「容器比 token 贵十倍」，而是「容器费随墙钟与预热池线性增长、与用户是否在说话无关」；1 万元／月的口述数字按单价反推不可能来自会话容器本身（100 人 × 20 会话 × 35 分钟仅约 $23／月），必然主要是固定设施与模型费——拆分交附录 A。
【事实】人机交互的经典阈值是 0.1 s／1 s／10 s（Nielsen 1993，NN/g 2014 重申「46 年未变」）：超过 10 s 用户注意力离开任务、回来要重新定向。Artificial Analysis 实测：最低 TTFT 0.28 s，DeepSeek V4 Pro 非推理 1.79 s、DeepSeek V4.1 Flash 1.15 s、GLM-5.3-Flash 约 2.5 s（含思考）；AWS 自己的 AgentCore 基准是冷启动约 2.9 s、预热后约 250 ms。25～60 s 首响是 NN/g 注意力阈值的 2.5～6 倍、是模型自身 TTFT 的 10～20 倍，延迟由运行时而非模型主导；CHI 2026 与 Andes（2024）两项研究都把首字延迟列为用户挫败与可信度的首要信号。
【事实】同类「理解需求→匹配供给」产品能找到一手技术描述的两家（Upwork Uma／Uma Recruiter，阿里云智能导购参考架构）都是模型＋平台工具调用循环：Upwork 写明三件套是 LLM「Agentic Brain」、对接站内搜索与推荐系统的「Agentic Tools」、「Agentic Memory」，微调 Llama 经 Fireworks 推理；阿里云方案是 Router Agent＋商品导购 Agent＋SQL／RAG 检索，部署在函数计算。两者均无每用户常驻沙箱。Fiverr Neo 只有投资者材料、无架构细节；淘宝问问内部实现无一手来源；Notion AI／飞书未覆盖。
【事实】反证成立但已被架构吸收：厂商一致把「要跑代码、生成文件、长时有状态」列为沙箱适用场景；本平台技术方案第 4.1 节已把这类工作切到「资产通道／平台代跑」，并写明它「与第 3 章 AI 助手的运行底座是两个问题……不共用同一个会话、同一份工具权限」（docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:455）。需要沙箱的是被组织的能力，不是组织者。
【待验证】三处主文要处理：(a) 技术方案第 3.1 节把「每会话独立的进程或容器、预热、跨主机会话恢复」写进运行环境层定义（…:250），这是以 daemon 为前提的措辞，重评后应改为「会话状态隔离与凭据隔离」而非容器；(b) 第 8.1 节「每个会话独立的进程或容器」（…:842）同理；(c) 国内网关到模型的实际 TTFT 要用公司网关实测，本文引的是 Artificial Analysis 对官方 API 的测量。

1　沙箱什么时候必要：四家厂商的官方口径

1.1　OpenAI

【事实】官方「Agents」总览页把三种运行时并列比较：Agents API（OpenAI 托管 Codex harness）、Agents SDK（「SDK 跑在你的应用里」）、Responses API（「直接调模型」）。表中「Execution environment」一行分别是「OpenAI hosted sandbox, self-hosted sandbox, or no sandbox」／「Your runtime and sandbox provider integrations」／「Your own execution environment」；「Tool execution」写「Service-connected tools, application function handlers, and an optional sandbox」。［S1］
【事实】Agents SDK 的工具分五类：Hosted tools（在 OpenAI 服务器上执行，含 CodeInterpreterTool「lets the LLM execute code in a sandboxed environment」）、本地运行时工具、FunctionTool（「wrap any Python function as a tool」）、Agents as tools、Codex 工具。沙箱只出现在其中一种工具里。［S2］
【事实】Code Interpreter 的 container 是「a fully sandboxed virtual machine」，按需自动创建或显式创建，20 分钟不用即过期，定价页单列「Containers：1 GB $0.03、4 GB $0.12、16 GB $0.48、64 GB $1.92 per 20-minute session per container」。［S3］［S4］
【事实】Agents SDK 的「Sandbox agents」页：「Use sandboxes when the agent needs to manipulate files, run commands, mount a … workspace」。［S5］

1.2　Anthropic

【事实】Managed Agents 总览的「When to use」列表：Long-running execution（「Tasks that run for minutes or hours with multiple tool calls」）、Cloud infrastructure（「Secure sandboxes with pre-installed packages」）、Stateful sessions（「Persistent filesystems」）、Scheduled execution。对照表写 Messages API「Best for: Custom agent loops and fine-grained control」，Managed Agents「Best for: Long-running tasks and asynchronous work」。［S6］
【事实】工程博客《Scaling Managed Agents: Decoupling the brain from the hands》（2026-04-08）：最初把 session、harness、sandbox 放进同一个容器，结果「every session paid the full container setup cost up front. Every session, even ones that would never touch the sandbox, had to clone the repo, boot the process…」，「That dead time is expressed in time-to-first-token (TTFT)… the latency the user most acutely feels」。改成 harness 出容器、容器仅在需要时经 execute(name, input) 拉起后，「our p50 TTFT dropped roughly 60% and p95 dropped over 90%」。［S7］
【事实】Claude Agent SDK 的 Hosting 页：SDK「spawns and supervises a claude CLI subprocess that owns a shell, a working directory, and session files on disk」，「One agent session maps to one subprocess」；建议规格「1 GiB RAM, 5 GiB disk, and 1 CPU per agent」；四种会话模式里「Long-running sessions」允许「hosting multiple SDK processes per container」；成本节写「Anthropic token cost typically dominates container infrastructure cost by an order of magnitude or more. A minimally provisioned container runs roughly $0.05 per hour」。并写「If you do not need infrastructure control, custom isolation, or your own data plane, consider Managed Agents」。［S8］
【事实】《Building effective agents》（2024-12，2026 年加注仍有效）：「the most successful implementations use simple, composable patterns rather than complex frameworks」；「For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough」；沙箱只出现在「We recommend extensive testing in sandboxed environments」（测试语境）。基本构件是「augmented LLM」（检索、工具、记忆），Routing 与 Orchestrator-workers 两种 workflow 正是「组织者」形态。［S9］

1.3　AWS

【事实】AgentCore Runtime：「Each session … Runs in a dedicated microVM with completely isolated CPU, memory, and filesystem resources」，空闲 15 分钟终止、最长 8 小时，「After session termination, the entire microVM is terminated and memory is sanitized」。［S10］
【事实】定价页把 Runtime、Browser、Code Interpreter 列为三个独立计费项，Code Interpreter 的描述是「enables agents execute code securely in sandbox environments」——代码沙箱是 Runtime 之外另一件产品。［S11］
【事实】AWS 官方文章《Minimizing startup latency with AgentCore Runtime》：冷启动＝「provision a microVM, load the deployment artifact, initialize the runtime environment, and execute startup logic」；2026-04 基准「Average latency fell from about 2.9 s to about 250 ms … p99 … from above 4.9 s to below 500 ms」（预热池对比冷启动）；预热池的代价是「you only pay for memory when the microVM is idle」。［S12］

1.4　Google

【事实】ADK 部署页列四条路径：Agent Runtime（托管）、Cloud Run、GKE、任意容器环境。Cloud Run 路径就是一个 get_fast_api_app() 起的 FastAPI 服务，--session_service_uri 指向 SQLAlchemy 数据库或 Agent Runtime 托管会话；未配置则会话存内存、实例回收即丢——即一个无状态容器服务多会话、会话状态外置。［S13］［S14］
【事实】Agent Platform 的「Scale」页把「Secure sandbox execution」（Code Execution、Computer Use）列为与 Agent Runtime、Sessions、Memory Bank 并列的独立能力；ADK 内置工具目录里 Code Execution／GKE Code Executor／「Persistent, stateful Linux sandboxes」都是工具项。［S15］［S16］

这一块能支撑什么：四家厂商的官方架构里，「判断类组织者助手」的默认宿主是普通服务进程（Responses／Messages API 直调、Agents SDK 进程内、ADK on Cloud Run），沙箱是模型按需调用的工具或长任务专用环境；Anthropic 自己的生产数据证明「先起容器再推理」直接抬高 TTFT。不能支撑什么：它们没有说「组织者助手绝不可以放进沙箱」，AgentCore 甚至把 microVM 隔离当作企业安全卖点（见第 5 节反证）；也没有任何一家给出「C 端对话助手」的专门参考架构。

2　每会话容器运行时的公开成本与延迟

2.1　单价对照

运行时	计费口径（官方原文要点）	1 会话小时的量级【推断：按右列规格】	空闲是否计费	会话时长上限	冷启动公开数据
AWS Fargate Linux/ARM（us-east-1）［S17］	vCPU $0.0000089944／s、内存 $0.0000009889／s；按秒计、1 分钟最低；「from the time you start to download your container image until the task terminates」	0.5 vCPU＋1 GB（daemon claude-code 规格）≈ $0.020；1 vCPU＋2 GB ≈ $0.040	是（整段墙钟）	无	AWS 未公布；本仓库 daemon README 实测冷路径拿到 wsUrl ≈42 s（见附录 A）
AWS AgentCore Runtime microVM v1［S11］	CPU $0.0895／vCPU-h（仅活跃时）＋内存 $0.00945／GB-h（整个会话含空闲）；1 秒最低、128 MB 最低内存	1 vCPU＋1 GB 全程活跃 ≈ $0.099；空闲只付内存 ≈ $0.009	内存计、CPU 不计	默认空闲 15 min 终止，最长 8 h	冷启动均值 ≈2.9 s、p99 >4.9 s；预热后 ≈250 ms［S12］
AWS AgentCore Runtime microVM v2［S11］	CPU $0.1276／vCPU-h、内存 $0.0169／GB-h（消费价）；空闲内存 120 s 后回收	1 vCPU＋1 GB ≈ $0.145	内存 120 s 后不计	同上	官方称「keeps cold-start latency consistent regardless of concurrency or image size」（快照恢复），未给数字［S10］
Google Agent Runtime／Code Execution［S18］	$0.085／vCPU-h＋$0.009／GiB-h；每月免费 50 vCPU-h＋100 GiB-h	1 vCPU＋1 GiB ≈ $0.094	按分配资源计	未在定价页写	未公布
E2B Sandbox［S19］	2 vCPU $0.000028／s＋4 GiB $0.000018／s（默认规格）；Pro 另收 $150／月基础费	默认规格 ≈ $0.166	是（运行即计）	Hobby 1 h、Pro 24 h	官方客户案例「A new sandbox can spin up in ~150ms」［S20］
Modal Sandbox［S21］	$0.00003942／物理核／s（最低 0.125 核）＋$0.00000667／GiB／s	1 核＋1 GiB ≈ $0.166；最低配 ≈ $0.03	是（可设 `idle_timeout`）	默认 5 min，最长 24 h	容器「boot in about one second」；默认空闲 60 s 回收［S22］
Anthropic Managed Agents［S23］	Session runtime $0.08／h，「accrues only while the session's status is running」；idle 不计	≈ $0.08（仅 running）	否	未写	见 S7 的 TTFT 改善数据
Anthropic code execution container［S23］	超过每月 1,550 免费小时后 $0.05／容器小时	≈ $0.05	—	—	—
OpenAI Containers（Hosted Shell／Code Interpreter）［S4］	1 GB $0.03 per 20-minute session；「Eligible container sessions will be billed by the minute, with a 5-minute minimum」	≈ $0.09	20 min 不用即过期	—	—
Claude Agent SDK 自托管（文档估算）［S8］	「A minimally provisioned container runs roughly $0.05 per hour」	≈ $0.05	取决于宿主	—	—

2.2　与「无状态按 token 计费」对照

模型官方定价（2026-09-21 访问）：

模型	输入（百万 token）	输出（百万 token）	备注
GLM-5.3-Flash［S24］	¥0.8	¥2.8	缓存命中 ¥0.23；限时五折
GLM-5.3（旗舰）［S24］	¥8	¥28	缓存命中 ¥2
DeepSeek Flash（V4.1）［S25］	$0.15 非高峰／$0.30 高峰（缓存未命中）	$0.6／$1.2	缓存命中 $0.003／$0.006
DeepSeek V4 Pro［S25］	$0.66／$1.32	$1.98／$3.96	同上

【推断】设一次组织者会话 15 轮、每轮 8,000 输入＋600 输出 token、不计缓存：

项	费用
GLM-5.3-Flash 一次会话	≈ ¥0.12
DeepSeek Flash 一次会话	≈ $0.023（非高峰）～$0.047（高峰）
DeepSeek V4 Pro 一次会话	≈ $0.19（高峰）
GLM-5.3 旗舰一次会话	≈ ¥1.2
Fargate 0.5 vCPU＋1 GB 跑 1 小时	≈ $0.020 ≈ ¥0.14（按 1 美元 ≈ 7.1 元，假设）
同规格：5 分钟对话＋30 分钟空闲回收（daemon 现行策略）	≈ 35 min × $0.020／h ≈ $0.012 ≈ ¥0.08

三条读法：

【推断】轻量模型下容器费与 token 费同量级：GLM-5.3-Flash 一次会话 ¥0.12 对一小时容器 ¥0.14。Anthropic Hosting 页「token 高一个量级」的结论以 Claude 价位为前提，换成国产 Flash 档就不成立；换成 GLM-5.3 旗舰则成立（¥1.2 对 ¥0.14）。汇报时不要引用「token 主导」当普适结论。
【事实＋推断】两种费用的形状不同：token 费随对话轮次与长度增长，用户不说话就为零；容器费随墙钟增长，含拉镜像、预热、空闲等待（Fargate 明文从拉镜像计起；AgentCore 空闲期计内存；OpenAI 20 分钟一档；Modal／E2B 运行即计）。C 端「大量短对话、长时间无人」的流量形状与后者不匹配，这是成本论点里最硬的一条。
【推断】口述「1 万元／月、人均 100 元」不可能来自会话容器本身：100 人 × 每月 20 次会话 × 35 分钟 × $0.020／h ≈ $23／月。按单价反推，该数字主要由固定设施（Router 常驻、NAT、预热池、EFS、日志）与模型费构成，拆分见附录 A。汇报时如果只说「每会话一容器很贵」会被对方用这组单价反驳；正确说法是「容器模型的成本随并发与空闲线性增长且有固定底座，和按 token 计费的形状不同」。

这一块能支撑什么：给出了所有主流每会话运行时的官方单价与计费形状，能证明「容器费按墙钟计、含空闲」与「token 费按工作量计」的结构差异，并能校验口述成本数字的来源。不能支撑什么：不能证明「容器比 token 贵一个量级」（轻量模型下不成立）；Fargate 官方没有冷启动数据，本仓库 daemon 的 42 s／18 s 是唯一一手实测；各家单价均为美国区列表价，国内区与公司折扣未查。

3　C 端对话产品的首响预期

【事实】Nielsen《Response Times: The 3 Important Limits》（1993 原文，2014 加注）：0.1 s「reacting instantaneously」；1 s「user's flow of thought to stay uninterrupted」；10 s「the limit for keeping the user's attention focused on the dialogue」，超过 10 s「users will want to perform other tasks while waiting」，需要进度指示与可中断入口，「Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds」；并明言这些指南「have been the same for 46 years」，不因实现技术而变。［S26］
【事实】Andes（arXiv 2404.16283，2024，密歇根大学等）把 LLM 流式服务的用户时间线分为「initial waiting phase」与「token consumption phase」：前者「the first token should be delivered to users before they lose patience. The target TTFT should depend on the service」；后者要求送出速度匹配阅读速度。QoE 以「Ideal Consumption Timeline」（低 TTFT＋按阅读速度递送）为基准度量偏差。［S27］
【事实】《Just-in-Time Tokens》（CHI EA 2026）：形成性研究（专家访谈 N=4、试点 N=12）发现「users are highly sensitive to initial delays and unpredictable mid-phrase pauses」，「initial delays frequently trigger disengagement」；对照实验（N=24）结论「blank-screen waits are a major frustration source, with first-token latency serving as a critical credibility signal for engagement」，且「cumulative TTFT … across multi-turn interactions breaks the interaction flow」。［S28］
【事实】Artificial Analysis 公开测量（TTFT＝发出请求到收到第一个 token）：全榜最低 Gemini 2.5 Flash-Lite 非推理 0.28 s；DeepSeek V4 Pro 非推理 1.79 s；DeepSeek V4.1 Flash（推理）1.15 s；GLM-5.3-Flash 约 2.50～2.53 s（含思考时间）、GLM-5.3 约 2.93 s。［S29］［S30］［S31］
【事实】AWS 的 AgentCore 冷启动基准 ≈2.9 s、预热后 ≈250 ms［S12］；Anthropic 把容器从会话启动路径上拿掉后 p50 TTFT 降约 60%［S7］。两家都把「运行时启动」当作可以也应该从首响里去掉的开销。

对「25～60 s 首响」的读法【推断】：

参照	数值	25～60 s 相当于
NN/g 注意力阈值	10 s	2.5～6 倍，用户按定义已离开任务
国产模型官方 API 的 TTFT	1.2～2.9 s	10～20 倍，延迟由运行时而非模型主导
AgentCore 冷启动	≈2.9 s	9～20 倍
预热后 AgentCore／E2B／Modal 启动	0.15～1 s	25～400 倍

daemon 第二轮起 TTFT 3～7 s（附录 A）也仍在 NN/g「1 s 流畅」阈值之外、接近 10 s 上限，但那部分主要是模型与 CLI 子进程开销，非本文范围。

这一块能支撑什么：有标准机构级阈值（NN/g）、两项同行评审研究（Andes、CHI 2026）与基准站实测三类独立来源，足以断言「几十秒首响对 C 端对话产品意味着用户按定义离开任务，且延迟来源是运行时」。不能支撑什么：没有找到「消费级 AI 助手首字延迟容忍度」的大样本一手调查（CHI 2026 样本为程序员、N=24）；Artificial Analysis 测的是官方 API，公司网关到模型的真实 TTFT 需实测；ClickHouse 工程博客的「interactive chat under ~1 s」经验值为二手参考、未列入结论。［S32］

4　同类产品怎么做

4.1　Upwork Uma／Uma Recruiter（一手：Upwork 官方博客、Meta 官方案例）

【事实】Upwork 2025-07 博客：Uma「acts across the full hiring flow: crafting effective job posts…, surfacing top matches, autonomously coordinating live interviews, evaluating candidates」；实现是「custom fine-tuning on open source LLMs」（Llama／Mistral／Qwen 可切换）＋「a function-calling layer and policy engine that determine when and how Uma should take action」＋「orchestration frameworks that allow Uma to delegate subtasks and monitor progress as a central coordinator」。［S33］
【事实】Meta 官方案例（2025-07-31）：Uma 用 Llama 3.1 70B＋LoRA，「At runtime, the Fireworks AI platform deploys LoRA adapters on demand」，多个任务专家（profile review、job analysis、proposal generation）共用一个基座；成效 engagement +58.8%、每 token 成本 −19.25%。［S34］
【事实】Upwork 2026-05 博客《Uma Recruiter: How We Built an Agentic Solution to Talent Matching and Hiring》：三个组件「an Agentic Brain powered by LLMs that orchestrates the process end-to-end; Agentic Tools that execute actions across Upwork's platform; and Agentic Memory」；工具「interface with Upwork's freelancer search and recommendation systems」；工程挑战是重试、回退、部分结果容忍、分布式追踪、按步骤路由到更便宜的小模型。全文没有沙箱、容器或代码执行。［S35］

4.2　阿里云「主动式智能导购 AI 助手」参考架构（一手：阿里云解决方案页）

【事实】「Multi-Agent 架构，其中 Router Agent 负责对用户问题进行意图分析，并路由到其它商品导购 Agent，商品导购 Agent 负责向顾客收集商品参数信息」；收集完成后「通过阿里云百炼应用进行智能商品检索，也可以使用 SQL 查询商品数据库」；部署在函数计算，「部署时长 10 分钟、预估费用 1 元」。无沙箱。［S36］
【事实＋边界】该页是阿里云的参考架构，不是淘宝问问的内部实现；淘宝问问只有媒体报道（第一财经 2023-09、新浪财经 2023-11），无一手技术描述。［S37］

4.3　Fiverr Neo（一手：投资者材料，无架构）

【事实】Fiverr 2023 Q2 业绩公告称 Neo 为「matching tool leveraging the latest neural networks technologies」；2025 Q2 电话会讲稿：「Two years ago, Fiverr launched Neo, the first-of-its-kind AI matching agent … Since then, Neo has evolved into a powerful AI engine that drives underlying KYC and matching across all of our front-end products」。没有任何运行时或架构细节，无法判定。［S38］［S39］

4.4　未覆盖

Notion AI、飞书助手未检索到一手技术描述，本文不作判断。

这一块能支撑什么：两家有一手技术描述的「需求理解→匹配」产品都是模型＋平台工具调用循环，工具直连站内搜索／推荐／数据库，没有为每个用户常驻沙箱。不能支撑什么：样本只有两家；Upwork 的博客未写会话隔离与部署形态（是否每请求无状态），只能确认「工具＝平台服务接口」这一点；Fiverr、淘宝问问无法判定。

5　反证：组织者助手什么时候确实需要沙箱，以及本平台怎么吸收

5.1　反证本身

【事实】厂商一致列出沙箱适用场景：Anthropic「Tasks that run for minutes or hours」「Persistent filesystems」［S6］；OpenAI「manipulate files, run commands, mount a workspace」［S5］；AgentCore 把「dedicated microVM … memory is sanitized」当作「crucial for enterprise security, particularly when dealing with non-deterministic AI processes」的隔离卖点［S10］；Google 把 Code Execution／Computer Use 归为「safely solve complex computational problems」［S15］。
【事实】Claude Agent SDK 的 harness 本身就是「拥有 shell 与工作目录的 CLI 子进程」［S8］，因此凡选 Claude Agent SDK 作引擎，每会话一进程（而非每会话一容器）是不可回避的；这是 2026-09-04 那份调研（archive/wiki过时页/wiki-过时页-0908归档/50-AI助手运行底座harness选型调研.md）推荐它时隐含的前提。
【推断】对本平台而言，下列情形确实需要执行环境：替用户代跑上传的技能资产、生成文件型产出物、执行外部代码、需要浏览器。若把这些塞进组织者会话，就回到「每会话一沙箱」。

5.2　架构已吸收

【事实】技术方案术语表把「资产＋运行时＝能力」定为已定口径：「自带运行时的提供方算『能力』，运行时留在提供方侧；只有技能描述而无运行时的按『资产』处理，平台代跑、效果由上传方负责。适配层据此分两条通道」（docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:17）。
【事实】第 2.3 节第一条不变量：「组织者与被组织者不混写。AI 助手是组织者，AI 业务能力是被组织对象……资产通道下平台代跑外部技能，但责任归上传方、不构成平台自有能力」（…:235）。
【事实】第 4.1 节两条通道表：资产通道「执行位置：平台侧代跑」「平台职责：提供运行环境、按资产声明执行、记录执行过程」（…:446-452）；随后一段：「资产通道在哪个运行环境里代跑，与第 3 章 AI 助手的运行底座是两个问题：AI 助手是组织者，资产是被组织的能力；两者可以共用同一套运行环境设施，但不共用同一个会话、同一份工具权限」（…:455）。
【事实】第 4.3 节任务生命周期定为「异步且长时」（…:472），第 4.6 节写明首个提供方（公司 AI 员工平台）「面向『一个用户、一个会话、一个容器』设计，与本平台『项目任务节点异步跑数分钟到数小时』的诉求有结构性错位」（…:544）——即每会话一容器的模型已被判定为能力侧的事，且连能力侧都要改造保活。
【事实】第 3.2 节三条硬要求（挂平台工具与权限、确认门以钩子插入、每步事件回记录链）与第 8.1 节「引擎进程不持有外部资源凭据，工具调用所需凭据收在平台侧」（…:297-312、…:842），都是对进程内工具面的要求，与是否有容器无关。

由此：反证成立的场景（跑代码、产文件、长时有状态）在本平台的责任划分里属于「被组织的能力」，走资产通道或能力通道；组织者只需一个能挂平台工具、能插确认门、能回放事件的服务进程。沙箱的需要是真实的，但它落在第 4 章，不落在第 3 章。

5.3　主文需处理的遗留措辞【待验证】

第 3.1 节运行环境层定义「每会话独立的进程或容器、并发与配额、凭据注入与出口管控、预热、跨主机会话恢复」（…:250）与第 8.1 节「每个会话独立的进程或容器、独立的工作目录与配置目录、降权运行」（…:842）：这是以 daemon 为前提写的。若采用进程内薄 harness，「隔离」的对象应改为会话状态、工具权限与凭据（逻辑隔离＋审计），「预热」「跨主机会话恢复」改为「无状态服务＋会话持久化」；第 8.3 节降级表「会话容器不可用、预热池耗尽」一行（…:866）同步改写。
第 3.8 节与第 8.4 节引用「一次长会话的 token 花费比宿主基础设施成本高一个数量级以上」（…:431、…:879）：来源是 Anthropic Hosting 页、以 Claude 价位为前提；按第 2.2 节推算，国产 Flash 档下不成立，主文应改为「视模型价位而定」并保留「成本控制重点在轮次上限与费用硬顶」的结论。

这一块能支撑什么：反证有一手来源且已被本平台架构文本明确吸收，汇报时可以正面承认「沙箱有用」再指出「它属于第 4 章」。不能支撑什么：资产通道的代跑环境选什么（AgentCore Code Interpreter／E2B／自建 Fargate 任务／复用 ndclaw 能力侧）本文不判断；技术方案第 3 章的遗留措辞要由主文修订。

来源清单（访问日期均为 2026-09-21）

编号	来源	URL
S1	OpenAI 开发者文档《Agents》总览（三种运行时对照表）	https://developers.openai.com/api/docs/guides/agents
S2	OpenAI Agents SDK《Tools》	https://openai.github.io/openai-agents-python/tools/
S3	OpenAI《Code Interpreter》工具指南（container、20 分钟过期）	https://platform.openai.com/docs/guides/tools-code-interpreter
S4	OpenAI API 定价页（Containers 计费）	https://developers.openai.com/api/docs/pricing
S5	OpenAI Agents SDK《Sandbox agents》	https://developers.openai.com/api/docs/guides/agents/sandboxes
S6	Anthropic《Claude Managed Agents overview》	https://platform.claude.com/docs/en/managed-agents/overview
S7	Anthropic 工程博客《Scaling Managed Agents: Decoupling the brain from the hands》（2026-04-08）	https://www.anthropic.com/engineering/managed-agents
S8	Anthropic《Claude Agent SDK: Hosting》	https://platform.claude.com/docs/en/agent-sdk/hosting
S9	Anthropic 工程博客《Building effective agents》（2024-12-19）	https://www.anthropic.com/engineering/building-effective-agents
S10	AWS 文档《Amazon Bedrock AgentCore Runtime: microVMs》	https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html
S11	AWS《Amazon Bedrock AgentCore Pricing》	https://aws.amazon.com/bedrock/agentcore/pricing/
S12	AWS re:Post 官方文章《Minimizing startup latency with Amazon Bedrock AgentCore Runtime》（AWS 员工署名，2026-04 基准）	https://repost.aws/articles/ARCJIn3t7aRC2FxiRTV1SuCA/minimizing-startup-latency-with-amazon-bedrock-agentcore-runtime
S13	Google ADK 文档《Deploying Your Agent》	https://adk.dev/deploy/
S14	Google ADK 文档《Deploy to Cloud Run》	https://adk.dev/deploy/cloud-run/
S15	Google Cloud 文档《Gemini Enterprise Agent Platform: Scale your agents》	https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale
S16	Google ADK 文档《Built-in tools》	https://adk.dev/tools/built-in-tools/
S17	AWS《AWS Fargate Pricing》（含 Linux/ARM 示例单价）	https://aws.amazon.com/fargate/pricing/
S18	Google Cloud《Gemini Enterprise Agent Platform pricing》（Agents 节）	https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing
S19	E2B《Pricing》	https://e2b.dev/pricing
S20	E2B 客户案例《How Manus Uses E2B…》（~150 ms 启动）	https://e2b.dev/customers/how-manus-uses-e2b-to-provide-agents-with-virtual-computers
S21	Modal《Pricing》（Sandbox 节）＋《Sandboxes》指南（超时与空闲）	https://modal.com/pricing ；https://modal.com/docs/guide/sandbox
S22	Modal《Cold start performance》	https://modal.com/docs/guide/cold-start
S23	Anthropic《Pricing》（Claude Managed Agents pricing、code execution container）	https://platform.claude.com/docs/en/about-claude/pricing
S24	智谱开放平台《模型 API 价格》	https://open.bigmodel.cn/pricing
S25	DeepSeek《Models & Pricing》	https://api-docs.deepseek.com/quick_start/pricing
S26	Nielsen Norman Group《Response Times: The 3 Important Limits》	https://www.nngroup.com/articles/response-times-3-important-limits/
S27	Liu 等《Andes: Defining and Enhancing Quality-of-Experience in LLM-Based Text Streaming Services》arXiv 2404.16283	https://arxiv.org/abs/2404.16283
S28	Zhu 等《Just-in-Time Tokens: Adaptive Token Pacing for Cognitive-Friendly LLM Streaming》CHI EA '26	https://dl.acm.org/doi/10.1145/3772363.3798936
S29	Artificial Analysis《Comparison of AI Models》（Latency 节）	https://artificialanalysis.ai/models
S30	Artificial Analysis DeepSeek 页（V4 Pro 1.79 s、V4.1 Flash 1.15 s）	https://artificialanalysis.ai/providers/deepseek ；https://artificialanalysis.ai/models/deepseek-v4-1-flash
S31	Artificial Analysis GLM-5.3-Flash 对比页（2.50 s／GLM-5.3 2.93 s）	https://artificialanalysis.ai/models/comparisons/glm-5-3-flash-vs-glm-5-3
S32	ClickHouse 工程博客《LLM inference latency: TTFT…》（二手参考，未入结论）	https://clickhouse.com/resources/engineering/llm-inference-latency
S33	Upwork 博客《Why Upwork Relies On In-House AI Research To Power Uma》（2025-07-23）	https://www.upwork.com/blog/why-upwork-relies-on-in-house-ai-research-to-power-uma-upworks-mindful-ai
S34	Meta AI 博客《How Upwork helps freelancers win more work with Llama》（2025-07-31）	https://ai.meta.com/blog/upwork-helps-freelancers-with-llama/
S35	Upwork 博客《Uma Recruiter: How We Built an Agentic Solution to Talent Matching and Hiring》（2026-05-05）	https://www.upwork.com/blog/uma-recruiter-how-we-built-an-agentic-solution-to-talent-matching-and-hiring
S36	阿里云解决方案《主动式智能导购 AI 助手构建》	https://www.aliyun.com/solution/tech-solution/build-an-ai-shopping-assistant
S37	第一财经《淘宝内测大模型 AI 应用「淘宝问问」》（媒体报道，仅证明无一手来源）	https://m.yicai.com/news/101857806.html
S38	Fiverr 投资者关系《Fiverr Announces Second Quarter 2023 Results》	https://investors.fiverr.com/node/8391/pdf
S39	Fiverr 投资者关系《Prepared Remarks Q2 2025 Earnings Call》	https://investors.fiverr.com/static-files/d74377ac-7022-4e15-acbe-e275b425ec5d

未取到的来源与原因：Anthropic Managed Agents 独立定价页不存在（404，定价并入 S23）；Fiverr 社区公告页需登录；知乎转载的淘宝技术文章被反爬拦截；Tavily 配额用尽，搜索改用 Firecrawl。

查看带行号的原始 Markdown（共 209 行）

1# 附录 C　业界证据：沙箱必要性、首响预期与运行时成本
2
3> 服务于《AI 助手运行底座重评》主文。回答一个问题：**「组织者型 C 端 AI 助手不该跑在每会话一沙箱容器的 agent 运行时上」这一判断，业界一手来源支不支持？** 同时主动找反证。
4> 全部来源为厂商官方文档／定价页／工程博客、论文或标准机构页面，访问日期统一为 2026-09-21；本机仓库事实标 `路径:行号`。标注约定：【事实】来源原文可查；【推断】由事实按公开单价推算，假设写明；【待验证】需实测或找更多来源。
5
6## 一页结论
7
81. 【事实】四家主流厂商的参考架构里，**「沙箱」都是 agent 按需调用的一个工具或一种可选环境，不是助手本身的宿主**。OpenAI 官方把三种运行时并列，其中 Agents API 的执行环境明写「hosted sandbox、self-hosted sandbox 或 **no sandbox**」，Agents SDK 的 `FunctionTool` 就是进程内 Python 函数，Code Interpreter 是独立计费的 container 工具；Anthropic 把 Managed Agents 定位为「分钟到小时级、要读写文件与跑代码」的长任务，且工程博客明确说把 harness 从容器里拿出来、只在需要时才拉容器后 **p50 TTFT 降约 60%、p95 降超 90%**；AWS AgentCore 把 Runtime（每会话一 microVM）与 Code Interpreter 分成两个产品分别计费；Google ADK 的官方部署路径之一就是 Cloud Run 上的普通 FastAPI 容器、多会话共用、会话存数据库，Code Execution 另作一个沙箱产品。
92. 【事实】每会话容器运行时的公开单价在 **$0.02～$0.17／会话小时**（Fargate ARM 0.5 vCPU＋1 GB 约 $0.02；AgentCore v1 约 $0.10；Google Agent Runtime 约 $0.094；E2B 默认规格约 $0.17；Modal Sandbox 1 核约 $0.17；Anthropic Managed Agents $0.08 仅计 running；OpenAI container $0.09）。这些计费的共同形状是：**按墙钟时间计、含空闲期**（Fargate 从拉镜像计到任务停止；AgentCore 空闲期仍计内存；OpenAI container 20 分钟一档），而模型 token 按工作量计。
103. 【推断】按公司网关走国产模型，一次 15 轮、每轮 8k 输入／600 输出的组织者会话，GLM-5.3-Flash 约 ¥0.12、DeepSeek Flash 约 $0.02～0.05、GLM-5.3 旗舰约 ¥1.2。**用轻量模型时容器小时费与 token 费同量级，Anthropic 文档「token 高一个量级」的结论只在旗舰价位成立**。所以成本论点的硬核不是「容器比 token 贵十倍」，而是「容器费随墙钟与预热池线性增长、与用户是否在说话无关」；1 万元／月的口述数字按单价反推不可能来自会话容器本身（100 人 × 20 会话 × 35 分钟仅约 $23／月），必然主要是固定设施与模型费——拆分交附录 A。
114. 【事实】人机交互的经典阈值是 0.1 s／1 s／10 s（Nielsen 1993，NN/g 2014 重申「46 年未变」）：超过 10 s 用户注意力离开任务、回来要重新定向。Artificial Analysis 实测：最低 TTFT 0.28 s，DeepSeek V4 Pro 非推理 1.79 s、DeepSeek V4.1 Flash 1.15 s、GLM-5.3-Flash 约 2.5 s（含思考）；AWS 自己的 AgentCore 基准是冷启动约 2.9 s、预热后约 250 ms。**25～60 s 首响是 NN/g 注意力阈值的 2.5～6 倍、是模型自身 TTFT 的 10～20 倍**，延迟由运行时而非模型主导；CHI 2026 与 Andes（2024）两项研究都把首字延迟列为用户挫败与可信度的首要信号。
125. 【事实】同类「理解需求→匹配供给」产品能找到一手技术描述的两家（Upwork Uma／Uma Recruiter，阿里云智能导购参考架构）都是**模型＋平台工具调用循环**：Upwork 写明三件套是 LLM「Agentic Brain」、对接站内搜索与推荐系统的「Agentic Tools」、「Agentic Memory」，微调 Llama 经 Fireworks 推理；阿里云方案是 Router Agent＋商品导购 Agent＋SQL／RAG 检索，部署在函数计算。**两者均无每用户常驻沙箱**。Fiverr Neo 只有投资者材料、无架构细节；淘宝问问内部实现无一手来源；Notion AI／飞书未覆盖。
136. 【事实】反证成立但已被架构吸收：厂商一致把「要跑代码、生成文件、长时有状态」列为沙箱适用场景；本平台技术方案第 4.1 节已把这类工作切到「资产通道／平台代跑」，并写明它「与第 3 章 AI 助手的运行底座是两个问题……不共用同一个会话、同一份工具权限」（`docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:455`）。需要沙箱的是被组织的能力，不是组织者。
147. 【待验证】三处主文要处理：(a) 技术方案第 3.1 节把「每会话独立的进程或容器、预热、跨主机会话恢复」写进运行环境层定义（`…:250`），这是以 daemon 为前提的措辞，重评后应改为「会话状态隔离与凭据隔离」而非容器；(b) 第 8.1 节「每个会话独立的进程或容器」（`…:842`）同理；(c) 国内网关到模型的实际 TTFT 要用公司网关实测，本文引的是 Artificial Analysis 对官方 API 的测量。
15
16---
17
18## 1　沙箱什么时候必要：四家厂商的官方口径
19
20### 1.1　OpenAI
21
22- 【事实】官方「Agents」总览页把三种运行时并列比较：Agents API（OpenAI 托管 Codex harness）、Agents SDK（「SDK 跑在你的应用里」）、Responses API（「直接调模型」）。表中「Execution environment」一行分别是「**OpenAI hosted sandbox, self-hosted sandbox, or no sandbox**」／「Your runtime and sandbox provider integrations」／「Your own execution environment」；「Tool execution」写「Service-connected tools, application function handlers, and an optional sandbox」。［S1］
23- 【事实】Agents SDK 的工具分五类：Hosted tools（在 OpenAI 服务器上执行，含 `CodeInterpreterTool`「lets the LLM execute code in a sandboxed environment」）、本地运行时工具、`FunctionTool`（「wrap any Python function as a tool」）、Agents as tools、Codex 工具。沙箱只出现在其中一种工具里。［S2］
24- 【事实】Code Interpreter 的 container 是「a fully sandboxed virtual machine」，按需自动创建或显式创建，**20 分钟不用即过期**，定价页单列「Containers：1 GB $0.03、4 GB $0.12、16 GB $0.48、64 GB $1.92 per 20-minute session per container」。［S3］［S4］
25- 【事实】Agents SDK 的「Sandbox agents」页：「Use sandboxes when the agent needs to manipulate files, run commands, mount a … workspace」。［S5］
26
27### 1.2　Anthropic
28
29- 【事实】Managed Agents 总览的「When to use」列表：Long-running execution（「Tasks that run for minutes or hours with multiple tool calls」）、Cloud infrastructure（「Secure sandboxes with pre-installed packages」）、Stateful sessions（「Persistent filesystems」）、Scheduled execution。对照表写 Messages API「Best for: Custom agent loops and fine-grained control」，Managed Agents「Best for: Long-running tasks and asynchronous work」。［S6］
30- 【事实】工程博客《Scaling Managed Agents: Decoupling the brain from the hands》（2026-04-08）：最初把 session、harness、sandbox 放进同一个容器，结果「every session paid the full container setup cost up front. Every session, even ones that would never touch the sandbox, had to clone the repo, boot the process…」，「That dead time is expressed in time-to-first-token (TTFT)… the latency the user most acutely feels」。改成 harness 出容器、容器仅在需要时经 `execute(name, input)` 拉起后，「**our p50 TTFT dropped roughly 60% and p95 dropped over 90%**」。［S7］
31- 【事实】Claude Agent SDK 的 Hosting 页：SDK「spawns and supervises a `claude` CLI subprocess that owns a shell, a working directory, and session files on disk」，「One agent session maps to one subprocess」；建议规格「1 GiB RAM, 5 GiB disk, and 1 CPU per agent」；四种会话模式里「Long-running sessions」允许「hosting multiple SDK processes per container」；成本节写「Anthropic token cost typically dominates container infrastructure cost by an order of magnitude or more. A minimally provisioned container runs roughly $0.05 per hour」。并写「If you do not need infrastructure control, custom isolation, or your own data plane, consider Managed Agents」。［S8］
32- 【事实】《Building effective agents》（2024-12，2026 年加注仍有效）：「the most successful implementations use simple, composable patterns rather than complex frameworks」；「For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough」；沙箱只出现在「We recommend extensive testing in sandboxed environments」（测试语境）。基本构件是「augmented LLM」（检索、工具、记忆），Routing 与 Orchestrator-workers 两种 workflow 正是「组织者」形态。［S9］
33
34### 1.3　AWS
35
36- 【事实】AgentCore Runtime：「Each session … Runs in a dedicated microVM with completely isolated CPU, memory, and filesystem resources」，空闲 15 分钟终止、最长 8 小时，「After session termination, the entire microVM is terminated and memory is sanitized」。［S10］
37- 【事实】定价页把 Runtime、Browser、Code Interpreter 列为三个独立计费项，Code Interpreter 的描述是「enables agents execute code securely in sandbox environments」——代码沙箱是 Runtime 之外另一件产品。［S11］
38- 【事实】AWS 官方文章《Minimizing startup latency with AgentCore Runtime》：冷启动＝「provision a microVM, load the deployment artifact, initialize the runtime environment, and execute startup logic」；2026-04 基准「Average latency fell from about 2.9 s to about 250 ms … p99 … from above 4.9 s to below 500 ms」（预热池对比冷启动）；预热池的代价是「you only pay for memory when the microVM is idle」。［S12］
39
40### 1.4　Google
41
42- 【事实】ADK 部署页列四条路径：Agent Runtime（托管）、**Cloud Run**、GKE、任意容器环境。Cloud Run 路径就是一个 `get_fast_api_app()` 起的 FastAPI 服务，`--session_service_uri` 指向 SQLAlchemy 数据库或 Agent Runtime 托管会话；未配置则会话存内存、实例回收即丢——即**一个无状态容器服务多会话、会话状态外置**。［S13］［S14］
43- 【事实】Agent Platform 的「Scale」页把「Secure sandbox execution」（Code Execution、Computer Use）列为与 Agent Runtime、Sessions、Memory Bank 并列的独立能力；ADK 内置工具目录里 Code Execution／GKE Code Executor／「Persistent, stateful Linux sandboxes」都是**工具项**。［S15］［S16］
44
45**这一块能支撑什么**：四家厂商的官方架构里，「判断类组织者助手」的默认宿主是普通服务进程（Responses／Messages API 直调、Agents SDK 进程内、ADK on Cloud Run），沙箱是模型按需调用的工具或长任务专用环境；Anthropic 自己的生产数据证明「先起容器再推理」直接抬高 TTFT。**不能支撑什么**：它们没有说「组织者助手绝不可以放进沙箱」，AgentCore 甚至把 microVM 隔离当作企业安全卖点（见第 5 节反证）；也没有任何一家给出「C 端对话助手」的专门参考架构。
46
47## 2　每会话容器运行时的公开成本与延迟
48
49### 2.1　单价对照
50
51| 运行时 | 计费口径（官方原文要点） | 1 会话小时的量级【推断：按右列规格】 | 空闲是否计费 | 会话时长上限 | 冷启动公开数据 |
52| --- | --- | --- | --- | --- | --- |
53| AWS Fargate Linux/ARM（us-east-1）［S17］ | vCPU $0.0000089944／s、内存 $0.0000009889／s；按秒计、**1 分钟最低**；「from the time you start to download your container image until the task terminates」 | 0.5 vCPU＋1 GB（daemon claude-code 规格）≈ **$0.020**；1 vCPU＋2 GB ≈ $0.040 | 是（整段墙钟） | 无 | AWS 未公布；本仓库 daemon README 实测冷路径拿到 wsUrl ≈42 s（见附录 A） |
54| AWS AgentCore Runtime microVM v1［S11］ | CPU $0.0895／vCPU-h（仅活跃时）＋内存 $0.00945／GB-h（整个会话含空闲）；1 秒最低、128 MB 最低内存 | 1 vCPU＋1 GB 全程活跃 ≈ **$0.099**；空闲只付内存 ≈ $0.009 | 内存计、CPU 不计 | 默认空闲 15 min 终止，最长 8 h | 冷启动均值 ≈2.9 s、p99 >4.9 s；预热后 ≈250 ms［S12］ |
55| AWS AgentCore Runtime microVM v2［S11］ | CPU $0.1276／vCPU-h、内存 $0.0169／GB-h（消费价）；空闲内存 120 s 后回收 | 1 vCPU＋1 GB ≈ **$0.145** | 内存 120 s 后不计 | 同上 | 官方称「keeps cold-start latency consistent regardless of concurrency or image size」（快照恢复），未给数字［S10］ |
56| Google Agent Runtime／Code Execution［S18］ | $0.085／vCPU-h＋$0.009／GiB-h；每月免费 50 vCPU-h＋100 GiB-h | 1 vCPU＋1 GiB ≈ **$0.094** | 按分配资源计 | 未在定价页写 | 未公布 |
57| E2B Sandbox［S19］ | 2 vCPU $0.000028／s＋4 GiB $0.000018／s（默认规格）；Pro 另收 $150／月基础费 | 默认规格 ≈ **$0.166** | 是（运行即计） | Hobby 1 h、Pro 24 h | 官方客户案例「A new sandbox can spin up in ~150ms」［S20］ |
58| Modal Sandbox［S21］ | $0.00003942／物理核／s（最低 0.125 核）＋$0.00000667／GiB／s | 1 核＋1 GiB ≈ **$0.166**；最低配 ≈ $0.03 | 是（可设 `idle_timeout`） | 默认 5 min，最长 24 h | 容器「boot in about one second」；默认空闲 60 s 回收［S22］ |
59| Anthropic Managed Agents［S23］ | Session runtime **$0.08／h**，「accrues only while the session's status is running」；idle 不计 | ≈ **$0.08**（仅 running） | 否 | 未写 | 见 S7 的 TTFT 改善数据 |
60| Anthropic code execution container［S23］ | 超过每月 1,550 免费小时后 $0.05／容器小时 | ≈ $0.05 | — | — | — |
61| OpenAI Containers（Hosted Shell／Code Interpreter）［S4］ | 1 GB $0.03 per 20-minute session；「Eligible container sessions will be billed by the minute, with a 5-minute minimum」 | ≈ **$0.09** | 20 min 不用即过期 | — | — |
62| Claude Agent SDK 自托管（文档估算）［S8］ | 「A minimally provisioned container runs roughly $0.05 per hour」 | ≈ $0.05 | 取决于宿主 | — | — |
63
64### 2.2　与「无状态按 token 计费」对照
65
66模型官方定价（2026-09-21 访问）：
67
68| 模型 | 输入（百万 token） | 输出（百万 token） | 备注 |
69| --- | --- | --- | --- |
70| GLM-5.3-Flash［S24］ | ¥0.8 | ¥2.8 | 缓存命中 ¥0.23；限时五折 |
71| GLM-5.3（旗舰）［S24］ | ¥8 | ¥28 | 缓存命中 ¥2 |
72| DeepSeek Flash（V4.1）［S25］ | $0.15 非高峰／$0.30 高峰（缓存未命中） | $0.6／$1.2 | 缓存命中 $0.003／$0.006 |
73| DeepSeek V4 Pro［S25］ | $0.66／$1.32 | $1.98／$3.96 | 同上 |
74
75【推断】设一次组织者会话 15 轮、每轮 8,000 输入＋600 输出 token、不计缓存：
76
77| 项 | 费用 |
78| --- | --- |
79| GLM-5.3-Flash 一次会话 | ≈ ¥0.12 |
80| DeepSeek Flash 一次会话 | ≈ $0.023（非高峰）～$0.047（高峰） |
81| DeepSeek V4 Pro 一次会话 | ≈ $0.19（高峰） |
82| GLM-5.3 旗舰一次会话 | ≈ ¥1.2 |
83| Fargate 0.5 vCPU＋1 GB 跑 1 小时 | ≈ $0.020 ≈ ¥0.14（按 1 美元 ≈ 7.1 元，假设） |
84| 同规格：5 分钟对话＋30 分钟空闲回收（daemon 现行策略） | ≈ 35 min × $0.020／h ≈ $0.012 ≈ ¥0.08 |
85
86三条读法：
87
881. 【推断】**轻量模型下容器费与 token 费同量级**：GLM-5.3-Flash 一次会话 ¥0.12 对一小时容器 ¥0.14。Anthropic Hosting 页「token 高一个量级」的结论以 Claude 价位为前提，换成国产 Flash 档就不成立；换成 GLM-5.3 旗舰则成立（¥1.2 对 ¥0.14）。汇报时不要引用「token 主导」当普适结论。
892. 【事实＋推断】**两种费用的形状不同**：token 费随对话轮次与长度增长，用户不说话就为零；容器费随墙钟增长，含拉镜像、预热、空闲等待（Fargate 明文从拉镜像计起；AgentCore 空闲期计内存；OpenAI 20 分钟一档；Modal／E2B 运行即计）。C 端「大量短对话、长时间无人」的流量形状与后者不匹配，这是成本论点里最硬的一条。
903. 【推断】口述「1 万元／月、人均 100 元」不可能来自会话容器本身：100 人 × 每月 20 次会话 × 35 分钟 × $0.020／h ≈ $23／月。按单价反推，该数字主要由固定设施（Router 常驻、NAT、预热池、EFS、日志）与模型费构成，拆分见附录 A。汇报时如果只说「每会话一容器很贵」会被对方用这组单价反驳；正确说法是「容器模型的成本随并发与空闲线性增长且有固定底座，和按 token 计费的形状不同」。
91
92**这一块能支撑什么**：给出了所有主流每会话运行时的官方单价与计费形状，能证明「容器费按墙钟计、含空闲」与「token 费按工作量计」的结构差异，并能校验口述成本数字的来源。**不能支撑什么**：不能证明「容器比 token 贵一个量级」（轻量模型下不成立）；Fargate 官方没有冷启动数据，本仓库 daemon 的 42 s／18 s 是唯一一手实测；各家单价均为美国区列表价，国内区与公司折扣未查。
93
94## 3　C 端对话产品的首响预期
95
96- 【事实】Nielsen《Response Times: The 3 Important Limits》（1993 原文，2014 加注）：0.1 s「reacting instantaneously」；1 s「user's flow of thought to stay uninterrupted」；10 s「the limit for keeping the user's attention focused on the dialogue」，超过 10 s「users will want to perform other tasks while waiting」，需要进度指示与可中断入口，「Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds」；并明言这些指南「have been the same for 46 years」，不因实现技术而变。［S26］
97- 【事实】Andes（arXiv 2404.16283，2024，密歇根大学等）把 LLM 流式服务的用户时间线分为「initial waiting phase」与「token consumption phase」：前者「the first token should be delivered to users before they lose patience. The target TTFT should depend on the service」；后者要求送出速度匹配阅读速度。QoE 以「Ideal Consumption Timeline」（低 TTFT＋按阅读速度递送）为基准度量偏差。［S27］
98- 【事实】《Just-in-Time Tokens》（CHI EA 2026）：形成性研究（专家访谈 N=4、试点 N=12）发现「users are highly sensitive to initial delays and unpredictable mid-phrase pauses」，「initial delays frequently trigger disengagement」；对照实验（N=24）结论「blank-screen waits are a major frustration source, with first-token latency serving as a critical credibility signal for engagement」，且「cumulative TTFT … across multi-turn interactions breaks the interaction flow」。［S28］
99- 【事实】Artificial Analysis 公开测量（TTFT＝发出请求到收到第一个 token）：全榜最低 Gemini 2.5 Flash-Lite 非推理 0.28 s；DeepSeek V4 Pro 非推理 1.79 s；DeepSeek V4.1 Flash（推理）1.15 s；GLM-5.3-Flash 约 2.50～2.53 s（含思考时间）、GLM-5.3 约 2.93 s。［S29］［S30］［S31］
100- 【事实】AWS 的 AgentCore 冷启动基准 ≈2.9 s、预热后 ≈250 ms［S12］；Anthropic 把容器从会话启动路径上拿掉后 p50 TTFT 降约 60%［S7］。两家都把「运行时启动」当作可以也应该从首响里去掉的开销。
101
102对「25～60 s 首响」的读法【推断】：
103
104| 参照 | 数值 | 25～60 s 相当于 |
105| --- | --- | --- |
106| NN/g 注意力阈值 | 10 s | 2.5～6 倍，用户按定义已离开任务 |
107| 国产模型官方 API 的 TTFT | 1.2～2.9 s | 10～20 倍，延迟由运行时而非模型主导 |
108| AgentCore 冷启动 | ≈2.9 s | 9～20 倍 |
109| 预热后 AgentCore／E2B／Modal 启动 | 0.15～1 s | 25～400 倍 |
110
111daemon 第二轮起 TTFT 3～7 s（附录 A）也仍在 NN/g「1 s 流畅」阈值之外、接近 10 s 上限，但那部分主要是模型与 CLI 子进程开销，非本文范围。
112
113**这一块能支撑什么**：有标准机构级阈值（NN/g）、两项同行评审研究（Andes、CHI 2026）与基准站实测三类独立来源，足以断言「几十秒首响对 C 端对话产品意味着用户按定义离开任务，且延迟来源是运行时」。**不能支撑什么**：没有找到「消费级 AI 助手首字延迟容忍度」的大样本一手调查（CHI 2026 样本为程序员、N=24）；Artificial Analysis 测的是官方 API，公司网关到模型的真实 TTFT 需实测；ClickHouse 工程博客的「interactive chat under ~1 s」经验值为二手参考、未列入结论。［S32］
114
115## 4　同类产品怎么做
116
117### 4.1　Upwork Uma／Uma Recruiter（一手：Upwork 官方博客、Meta 官方案例）
118
119- 【事实】Upwork 2025-07 博客：Uma「acts across the full hiring flow: crafting effective job posts…, surfacing top matches, autonomously coordinating live interviews, evaluating candidates」；实现是「custom fine-tuning on open source LLMs」（Llama／Mistral／Qwen 可切换）＋「a function-calling layer and policy engine that determine when and how Uma should take action」＋「orchestration frameworks that allow Uma to delegate subtasks and monitor progress as a central coordinator」。［S33］
120- 【事实】Meta 官方案例（2025-07-31）：Uma 用 Llama 3.1 70B＋LoRA，「At runtime, the Fireworks AI platform deploys LoRA adapters on demand」，多个任务专家（profile review、job analysis、proposal generation）共用一个基座；成效 engagement +58.8%、每 token 成本 −19.25%。［S34］
121- 【事实】Upwork 2026-05 博客《Uma Recruiter: How We Built an Agentic Solution to Talent Matching and Hiring》：三个组件「an Agentic Brain powered by LLMs that orchestrates the process end-to-end; Agentic Tools that execute actions across Upwork's platform; and Agentic Memory」；工具「interface with Upwork's freelancer search and recommendation systems」；工程挑战是重试、回退、部分结果容忍、分布式追踪、按步骤路由到更便宜的小模型。**全文没有沙箱、容器或代码执行**。［S35］
122
123### 4.2　阿里云「主动式智能导购 AI 助手」参考架构（一手：阿里云解决方案页）
124
125- 【事实】「Multi-Agent 架构，其中 Router Agent 负责对用户问题进行意图分析，并路由到其它商品导购 Agent，商品导购 Agent 负责向顾客收集商品参数信息」；收集完成后「通过阿里云百炼应用进行智能商品检索，也可以使用 SQL 查询商品数据库」；部署在函数计算，「部署时长 10 分钟、预估费用 1 元」。**无沙箱**。［S36］
126- 【事实＋边界】该页是阿里云的参考架构，不是淘宝问问的内部实现；淘宝问问只有媒体报道（第一财经 2023-09、新浪财经 2023-11），无一手技术描述。［S37］
127
128### 4.3　Fiverr Neo（一手：投资者材料，无架构）
129
130- 【事实】Fiverr 2023 Q2 业绩公告称 Neo 为「matching tool leveraging the latest neural networks technologies」；2025 Q2 电话会讲稿：「Two years ago, Fiverr launched Neo, the first-of-its-kind AI matching agent … Since then, Neo has evolved into a powerful AI engine that drives underlying KYC and matching across all of our front-end products」。**没有任何运行时或架构细节**，无法判定。［S38］［S39］
131
132### 4.4　未覆盖
133
134Notion AI、飞书助手未检索到一手技术描述，本文不作判断。
135
136**这一块能支撑什么**：两家有一手技术描述的「需求理解→匹配」产品都是模型＋平台工具调用循环，工具直连站内搜索／推荐／数据库，没有为每个用户常驻沙箱。**不能支撑什么**：样本只有两家；Upwork 的博客未写会话隔离与部署形态（是否每请求无状态），只能确认「工具＝平台服务接口」这一点；Fiverr、淘宝问问无法判定。
137
138## 5　反证：组织者助手什么时候确实需要沙箱，以及本平台怎么吸收
139
140### 5.1　反证本身
141
142- 【事实】厂商一致列出沙箱适用场景：Anthropic「Tasks that run for minutes or hours」「Persistent filesystems」［S6］；OpenAI「manipulate files, run commands, mount a workspace」［S5］；AgentCore 把「dedicated microVM … memory is sanitized」当作「crucial for enterprise security, particularly when dealing with non-deterministic AI processes」的隔离卖点［S10］；Google 把 Code Execution／Computer Use 归为「safely solve complex computational problems」［S15］。
143- 【事实】Claude Agent SDK 的 harness 本身就是「拥有 shell 与工作目录的 CLI 子进程」［S8］，因此凡选 Claude Agent SDK 作引擎，每会话一进程（而非每会话一容器）是不可回避的；这是 2026-09-04 那份调研（`archive/wiki过时页/wiki-过时页-0908归档/50-AI助手运行底座harness选型调研.md`）推荐它时隐含的前提。
144- 【推断】对本平台而言，下列情形确实需要执行环境：替用户代跑上传的技能资产、生成文件型产出物、执行外部代码、需要浏览器。若把这些塞进组织者会话，就回到「每会话一沙箱」。
145
146### 5.2　架构已吸收
147
148- 【事实】技术方案术语表把「资产 ＋ 运行时 ＝ 能力」定为已定口径：「自带运行时的提供方算『能力』，运行时留在提供方侧；只有技能描述而无运行时的按『资产』处理，平台代跑、效果由上传方负责。适配层据此分两条通道」（`docs/reports/2026-09-AI创业平台技术方案/AI创业平台技术方案.md:17`）。
149- 【事实】第 2.3 节第一条不变量：「组织者与被组织者不混写。AI 助手是组织者，AI 业务能力是被组织对象……资产通道下平台代跑外部技能，但责任归上传方、不构成平台自有能力」（`…:235`）。
150- 【事实】第 4.1 节两条通道表：资产通道「执行位置：平台侧代跑」「平台职责：提供运行环境、按资产声明执行、记录执行过程」（`…:446-452`）；随后一段：「资产通道在哪个运行环境里代跑，与第 3 章 AI 助手的运行底座是两个问题：AI 助手是组织者，资产是被组织的能力；两者可以共用同一套运行环境设施，但不共用同一个会话、同一份工具权限」（`…:455`）。
151- 【事实】第 4.3 节任务生命周期定为「异步且长时」（`…:472`），第 4.6 节写明首个提供方（公司 AI 员工平台）「面向『一个用户、一个会话、一个容器』设计，与本平台『项目任务节点异步跑数分钟到数小时』的诉求有结构性错位」（`…:544`）——即每会话一容器的模型已被判定为**能力侧**的事，且连能力侧都要改造保活。
152- 【事实】第 3.2 节三条硬要求（挂平台工具与权限、确认门以钩子插入、每步事件回记录链）与第 8.1 节「引擎进程不持有外部资源凭据，工具调用所需凭据收在平台侧」（`…:297-312`、`…:842`），都是对**进程内工具面**的要求，与是否有容器无关。
153
154由此：反证成立的场景（跑代码、产文件、长时有状态）在本平台的责任划分里属于「被组织的能力」，走资产通道或能力通道；组织者只需一个能挂平台工具、能插确认门、能回放事件的服务进程。**沙箱的需要是真实的，但它落在第 4 章，不落在第 3 章**。
155
156### 5.3　主文需处理的遗留措辞【待验证】
157
158- 第 3.1 节运行环境层定义「每会话独立的进程或容器、并发与配额、凭据注入与出口管控、预热、跨主机会话恢复」（`…:250`）与第 8.1 节「每个会话独立的进程或容器、独立的工作目录与配置目录、降权运行」（`…:842`）：这是以 daemon 为前提写的。若采用进程内薄 harness，「隔离」的对象应改为会话状态、工具权限与凭据（逻辑隔离＋审计），「预热」「跨主机会话恢复」改为「无状态服务＋会话持久化」；第 8.3 节降级表「会话容器不可用、预热池耗尽」一行（`…:866`）同步改写。
159- 第 3.8 节与第 8.4 节引用「一次长会话的 token 花费比宿主基础设施成本高一个数量级以上」（`…:431`、`…:879`）：来源是 Anthropic Hosting 页、以 Claude 价位为前提；按第 2.2 节推算，国产 Flash 档下不成立，主文应改为「视模型价位而定」并保留「成本控制重点在轮次上限与费用硬顶」的结论。
160
161**这一块能支撑什么**：反证有一手来源且已被本平台架构文本明确吸收，汇报时可以正面承认「沙箱有用」再指出「它属于第 4 章」。**不能支撑什么**：资产通道的代跑环境选什么（AgentCore Code Interpreter／E2B／自建 Fargate 任务／复用 ndclaw 能力侧）本文不判断；技术方案第 3 章的遗留措辞要由主文修订。
162
163---
164
165## 来源清单（访问日期均为 2026-09-21）
166
167| 编号 | 来源 | URL |
168| --- | --- | --- |
169| S1 | OpenAI 开发者文档《Agents》总览（三种运行时对照表） | https://developers.openai.com/api/docs/guides/agents |
170| S2 | OpenAI Agents SDK《Tools》 | https://openai.github.io/openai-agents-python/tools/ |
171| S3 | OpenAI《Code Interpreter》工具指南（container、20 分钟过期） | https://platform.openai.com/docs/guides/tools-code-interpreter |
172| S4 | OpenAI API 定价页（Containers 计费） | https://developers.openai.com/api/docs/pricing |
173| S5 | OpenAI Agents SDK《Sandbox agents》 | https://developers.openai.com/api/docs/guides/agents/sandboxes |
174| S6 | Anthropic《Claude Managed Agents overview》 | https://platform.claude.com/docs/en/managed-agents/overview |
175| S7 | Anthropic 工程博客《Scaling Managed Agents: Decoupling the brain from the hands》（2026-04-08） | https://www.anthropic.com/engineering/managed-agents |
176| S8 | Anthropic《Claude Agent SDK: Hosting》 | https://platform.claude.com/docs/en/agent-sdk/hosting |
177| S9 | Anthropic 工程博客《Building effective agents》（2024-12-19） | https://www.anthropic.com/engineering/building-effective-agents |
178| S10 | AWS 文档《Amazon Bedrock AgentCore Runtime: microVMs》 | https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html |
179| S11 | AWS《Amazon Bedrock AgentCore Pricing》 | https://aws.amazon.com/bedrock/agentcore/pricing/ |
180| S12 | AWS re:Post 官方文章《Minimizing startup latency with Amazon Bedrock AgentCore Runtime》（AWS 员工署名，2026-04 基准） | https://repost.aws/articles/ARCJIn3t7aRC2FxiRTV1SuCA/minimizing-startup-latency-with-amazon-bedrock-agentcore-runtime |
181| S13 | Google ADK 文档《Deploying Your Agent》 | https://adk.dev/deploy/ |
182| S14 | Google ADK 文档《Deploy to Cloud Run》 | https://adk.dev/deploy/cloud-run/ |
183| S15 | Google Cloud 文档《Gemini Enterprise Agent Platform: Scale your agents》 | https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale |
184| S16 | Google ADK 文档《Built-in tools》 | https://adk.dev/tools/built-in-tools/ |
185| S17 | AWS《AWS Fargate Pricing》（含 Linux/ARM 示例单价） | https://aws.amazon.com/fargate/pricing/ |
186| S18 | Google Cloud《Gemini Enterprise Agent Platform pricing》（Agents 节） | https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing |
187| S19 | E2B《Pricing》 | https://e2b.dev/pricing |
188| S20 | E2B 客户案例《How Manus Uses E2B…》（~150 ms 启动） | https://e2b.dev/customers/how-manus-uses-e2b-to-provide-agents-with-virtual-computers |
189| S21 | Modal《Pricing》（Sandbox 节）＋《Sandboxes》指南（超时与空闲） | https://modal.com/pricing ；https://modal.com/docs/guide/sandbox |
190| S22 | Modal《Cold start performance》 | https://modal.com/docs/guide/cold-start |
191| S23 | Anthropic《Pricing》（Claude Managed Agents pricing、code execution container） | https://platform.claude.com/docs/en/about-claude/pricing |
192| S24 | 智谱开放平台《模型 API 价格》 | https://open.bigmodel.cn/pricing |
193| S25 | DeepSeek《Models & Pricing》 | https://api-docs.deepseek.com/quick_start/pricing |
194| S26 | Nielsen Norman Group《Response Times: The 3 Important Limits》 | https://www.nngroup.com/articles/response-times-3-important-limits/ |
195| S27 | Liu 等《Andes: Defining and Enhancing Quality-of-Experience in LLM-Based Text Streaming Services》arXiv 2404.16283 | https://arxiv.org/abs/2404.16283 |
196| S28 | Zhu 等《Just-in-Time Tokens: Adaptive Token Pacing for Cognitive-Friendly LLM Streaming》CHI EA '26 | https://dl.acm.org/doi/10.1145/3772363.3798936 |
197| S29 | Artificial Analysis《Comparison of AI Models》（Latency 节） | https://artificialanalysis.ai/models |
198| S30 | Artificial Analysis DeepSeek 页（V4 Pro 1.79 s、V4.1 Flash 1.15 s） | https://artificialanalysis.ai/providers/deepseek ；https://artificialanalysis.ai/models/deepseek-v4-1-flash |
199| S31 | Artificial Analysis GLM-5.3-Flash 对比页（2.50 s／GLM-5.3 2.93 s） | https://artificialanalysis.ai/models/comparisons/glm-5-3-flash-vs-glm-5-3 |
200| S32 | ClickHouse 工程博客《LLM inference latency: TTFT…》（二手参考，未入结论） | https://clickhouse.com/resources/engineering/llm-inference-latency |
201| S33 | Upwork 博客《Why Upwork Relies On In-House AI Research To Power Uma》（2025-07-23） | https://www.upwork.com/blog/why-upwork-relies-on-in-house-ai-research-to-power-uma-upworks-mindful-ai |
202| S34 | Meta AI 博客《How Upwork helps freelancers win more work with Llama》（2025-07-31） | https://ai.meta.com/blog/upwork-helps-freelancers-with-llama/ |
203| S35 | Upwork 博客《Uma Recruiter: How We Built an Agentic Solution to Talent Matching and Hiring》（2026-05-05） | https://www.upwork.com/blog/uma-recruiter-how-we-built-an-agentic-solution-to-talent-matching-and-hiring |
204| S36 | 阿里云解决方案《主动式智能导购 AI 助手构建》 | https://www.aliyun.com/solution/tech-solution/build-an-ai-shopping-assistant |
205| S37 | 第一财经《淘宝内测大模型 AI 应用「淘宝问问」》（媒体报道，仅证明无一手来源） | https://m.yicai.com/news/101857806.html |
206| S38 | Fiverr 投资者关系《Fiverr Announces Second Quarter 2023 Results》 | https://investors.fiverr.com/node/8391/pdf |
207| S39 | Fiverr 投资者关系《Prepared Remarks Q2 2025 Earnings Call》 | https://investors.fiverr.com/static-files/d74377ac-7022-4e15-acbe-e275b425ec5d |
208
209未取到的来源与原因：Anthropic Managed Agents 独立定价页不存在（404，定价并入 S23）；Fiverr 社区公告页需登录；知乎转载的淘宝技术文章被反爬拦截；Tavily 配额用尽，搜索改用 Firecrawl。

2026 年 9 月 21—27 日工作汇报附件 · 取证日期 2026-09-28 · 原文 SHA-256：0149ac474fb366cec3671e229dd2b529b53a6d105baa3b8f8400e21b6b64aa0f

附录 C 业界证据：沙箱必要性、首响预期与运行时成本

一页结论

1 沙箱什么时候必要：四家厂商的官方口径

1.1 OpenAI

1.2 Anthropic

1.3 AWS

1.4 Google

2 每会话容器运行时的公开成本与延迟

2.1 单价对照

2.2 与「无状态按 token 计费」对照

3 C 端对话产品的首响预期

4 同类产品怎么做

4.1 Upwork Uma／Uma Recruiter（一手：Upwork 官方博客、Meta 官方案例）

4.2 阿里云「主动式智能导购 AI 助手」参考架构（一手：阿里云解决方案页）

4.3 Fiverr Neo（一手：投资者材料，无架构）

4.4 未覆盖

5 反证：组织者助手什么时候确实需要沙箱，以及本平台怎么吸收

5.1 反证本身

5.2 架构已吸收

5.3 主文需处理的遗留措辞【待验证】