为什么自建 Agent 内核，
而不是复用 Claude Code

00先承认前提：内核确实是「临摹品」

不回避：FFAI 的主循环、auto-compact 阈值公式（window − 20000 − 13000）、重试语言（指数退避 ±25% jitter / 后台请求遇过载直接放弃 / 连续 3 次过载换模型）、记忆注入截断（200 行 / 25KB）、<tool_use_error> 反馈闭环、两轴协作模式，全部是对 Claude Code 的有意识临摹——设计文档逐处标了出处。

所以问题不是「我们能不能写出这个内核」（能，且已在生产运行），而是「既然长得像，为什么不用原装的」。答案的骨架一句话：

01五条决定性原因

任何一条单独成立，都足以否决「换内核」。五条同时成立。

02三条次要但真实的原因

03反事实检验：什么条件下应该用 CC / Agent SDK

诚实列出翻盘条件，防止本文变成永久教条。任一行状态翻转时，应重开评估，而不是引用本文否决。

04「复用 Claude Code」的正确姿势

不换内核 ≠ 不用 CC。我们实际在做（和将要做）的三件事：

05FAQ：「Claude 不是有企业版吗？」

最容易混淆的一层追问。答案：Claude 的企业形态企业化的是「员工用 Claude」这件事；FFAI 要企业化的是「模型操作我们的业务系统」这件事——两个「企业」不在同一个位置。

Claude 的企业形态是两样东西：① Claude Enterprise（claude.ai 企业席位：SSO/SAML、席位与域管理、审计日志、数据不用于训练）；② Claude Code 企业管理（managed settings 策略下发、用量/费用管控、Bedrock/Vertex 合规接入）。它们是采购合规层——让 IT 部门敢把 Claude 发给全员。但逐维对照我们的需求，会发现它答的不是同一道题：

FAQ-2：「工具可见性 MCP 能动态过滤、上下文注入 spawn 时能拼进去啊？」

2026-07-07 的连环追问，逐条认账之后，论证收敛到它的最终形态。

都对：MCP tools/list 是 per-session 动态的（还有 list_changed 通知 + readOnly/destructive 注解）；内核由我们 spawn，system prompt / CLAUDE.md / append-system-prompt 都是我们拼的，per-turn 动态注入可走 UserPromptSubmit hook 注 additionalContext——连「共享上下文不注入」都成立。照此推演，任何「X 做不到」的具体清单都会被逐条失守，因为 CC 的旋钮面每个版本都在扩大。所以正确的论证不是阵地战，而是看什么撑到最后：

06FAQ-3：「Agent 长在业务系统上，会不会高耦合？」

2026-07-07 追问。判定：是好方式——代码耦合实际很低（插件反转），真正的耦合在进程/部署层，那才是要管理的部分。行动项登记于 decisions.md D76。

前置心智模型：本机 vs 服务器 · 两种并发容量 · SSE 的账怎么算

06bFAQ-4：「那用 CC 内核，在后端 API 处插我们的路由代理呢？」

即社区 claude-code-router 模式：Anthropic 协议代理 + ANTHROPIC_BASE_URL 指向。结论：demo 级可行，企业内核级不可行；但想法的内核在 worker 方案里值钱。

• 代理 = 入站 Anthropic 全协议仿真：prompt caching 断点/计价、beta sticky latch、thinking signature、细粒度工具流式——逐个仿真或剥离，比我们现有协议层（出站方向 2,232 行）更重且方向相反，永远追 CC 版本。
• 最阴险的是失同步：CC 内部状态机（压缩阈值/成本/重试）全按「它以为的 claude 模型」运转——路由到 128K 窗口模型，CC 以为有 200K → 压缩不触发 → 400 爆窗。CC 循环与 Anthropic 协议共生进化，代理骗得了请求格式，骗不了内部假设。
• 只攻下 R2 的一半，R1/R3/R4/R5 纹丝不动；胶水清单反增最重一块（协议仿真代理）。
• 值钱的落点：沙箱 CC worker 配我们的 LLM 出口网关——统一记账 + 出网合规 + 审计，只做管控不做跨模型路由（worker 用真 Claude，保真度 100%）。「API 层插一手」的价值全留，死穴全避。

06cFAQ-5：「E28 每人一个工作区之后，容器里跑 CC 当运行时呢？」

反方最强版本——「每人一个持久容器」恰好重建了 CC 的原生栖息地（一人一台机器），本题因此重开。诚实结论：此架构成立；真正剩下的决定因素只有三个，其中最硬的一个不是工程问题。

先补事实：Agent SDK 有什么（「封装 CLI」的正解就是 SDK——官方 CLI 封装，结构化消息流非拦 stdout）：进程内工具定义（JS 函数即工具）、hooks 全套回调、canUseTool 程序化审批、systemPrompt/CLAUDE.md/cwd 注入、permissionMode、resume/fork。设想的三类注入（工具/记忆/执行控制）SDK 全部一等支持；唯一没有的是非 Anthropic 模型。E26 文件记忆本就临摹 CC，工作区语义直接对上——很多东西是对齐而非别扭。

关键印证：Anthropic 自己把 CC 搬上服务器时，也没做共享多租户循环——而是给每个会话发一台机器。「现有循环当共享控制面 + 每人容器当工作面」不是分裂脑，是控制面/工作面的标准云架构；CC on the Web 就是它的单模型子集，我们多的三样（多模型/业务工具/org 治理）恰是必须自有循环的三个理由。

追问查证：为什么不共享？成本呢？ChatGPT 怎么做的？

追问：「直接全部给 CC 不是更简单吗？」

先纠正前提：两种方案里「调什么工具」都是模型决定的——循环（我们的或 CC 的）只组装工具清单 + 执行 + 治理。问题不是「谁决策」（伪问题），是「谁当 harness」。「更简单」的账：真省 1.5-2 万行（但那是维护最便宜的临摹部分）；复杂度守恒——转移进胶水（85 工具 MCP 化 + token 管道 + 多端胶水 + 审计摄取，且长在我们不控制的接口上）；净新增两笔硬成本——常见情形变慢（业务轻查询占绝对主导，每轮付容器唤醒 + spawn 1-3s，违反「为常见情形优化」原则）+ 模型锁定。「全部给 CC」对编码为主的个人助理确实更简单——那个产品 Anthropic 已经做了（CC web）；重心决定 harness 归属。可量化翻盘触发器：上线数据若显示重编码/文件任务占绝对主导（>70%），本题重开。

06dFAQ-6：「终局是不是每人一个？只共享是不是不是最终形态？」

对了三分之二——要精确到「每人一个什么」。个人助理由三个平面组成：

终章：「为什么 CC 没做三平面？Codex 确定做了吗？」

三家都有三平面，区别在「折叠没折叠」和「状态面事实源放哪」：本地 CC 三面折叠在用户机器上——且折叠是对的（三平面分离是保管人架构的产物，单一信任域里分层是纯开销）；CC on the Web = 控制面共享（账号/调度/计费）+ 循环随执行面进 VM（路径依赖）+ 状态面外包 GitHub（clone 是临时副本、事实源在 git、产出走 PR——不是没有状态面，是不需要自建）；Codex cloud 90% 官方确证（每任务容器、agent 阶段断网、缓存+resume）+ 10% 标注推断（模型在推理集群 → 编排语义在 OpenAI 侧），状态面同样外包 git。

边界钉死：执行面包括哪些？对话属于哪个面？

判据一句话：这段计算是谁写的？工程师写的、有界的 → 控制面；LLM/用户临时生成的、无界的 → 执行面；不是计算是数据 → 状态面。

• 执行面两个物理位置：云个人容器（code_session_exec / cli_exec / 未来 CC worker / 用户自编程逻辑）+ 用户本机（Desktop client 轨 file/clipboard/shell，本地强制层 I-28）。
• 两个易混项不在执行面：业务工具调用（查审批/建单）= 控制面活动（共享进程内、工程师写死、有界）；工作区文件读写 = 控制面代表用户访问状态面（直接 FS/DB API 不开容器）。有界业务工具在控制面，无界命令/代码才在执行面。
• 对话 = 控制面的活动，产生状态面的数据，途中把无界计算外包给执行面。典型 turn：「分析 Excel 出图表」→ 控制面循环 → 状态面取文件 → 执行面跑 Python → 控制面治理 → 沉淀回状态面。LLM 推理本身是被控制面调用的共享智能。
• 状态面与执行面可以合并吗？物理已合一半（D55 卷统一：容器挂工作区同一块盘 = 「个人云电脑」体验），逻辑不能合——① 生命周期：执行可抛弃（GC 销容器保卷、suspend RAM 归零文件在），状态珍贵要备份；② 信任：状态必须在执行面被攻陷时幸存；③ 访问路径：控制面要直读状态（记忆/manifest 不开容器），容器大部分时间停着。正确关系：执行面是状态面外面那层「可抛弃的计算外壳」——合体呈现，分层实现；「销毁容器保留卷」能成立本身就证明两者是两个东西。用户自己的桌面机天然合一没问题（他的信任域）；云上必须分层（我们是保管人——计算可以炸，数据不能丢）。

07最终建议：模型可以租，循环必须自有

「总体上自建更好，还是 Claude 内核 + 外层控制？」的定稿回答（2026-07-07）。

Claude 的三个正确位置：① Claude 模型进 ModelRouter（已在用）；② CC 进用户沙箱当编程 worker（E28/E31 后立项评估——拿它全球最强的编码深度，不交出循环）；③ 设计临摹 + 上游对标（已固化，#1932 模式）。重估触发：Anthropic 若发布多 provider、可编程循环的多租户服务端 agent 运行时，本题重做（详见 §03 反事实表）。

08落地路线：定型方案与三阶段施工

「哪个方案更好、具体怎么做」的定稿（2026-07-07）。定型：自建控制面 + 内嵌 Worker 执行面——每个部件被推演与两巨头实践双重锁定，无其他候选。

终态架构
控制面（现有循环，保持并加固）
  身份/RBAC · ModelRouter(5家) · 治理收口 · 配额 · 审计链 · Teams/Web/cron
       │ 有界业务工具(service轨,进程内)      │ 无界任务派 worker
       ▼                                    ▼
状态面（E27/E26，已有）              执行面（E28 容器，已有）
  工作区 ~/ · 记忆 · PG/blob          + CC/Codex CLI worker 进容器
  （欠：卷备份）                      + LLM 出口网关（凭据不进箱）

双循环走查：「帮我把销售数据做成 Next.js 仪表盘」

一次编码任务的完整旅程（两个循环不纠缠）
① 用户在 FFAI 对话框提需求
② 我们的循环：组 context（记忆/manifest）→ 路由 → 模型调 delegate_coding_task
③ 治理收口放行 → 返 taskId（外层循环继续活着，可陪用户聊别的）
④ 容器 ensure-running(~1s) → runner 用 Agent SDK 起 CC 会话（cwd=工作区卷）
⑤ CC 自己的循环自主跑：Read→Edit→Bash 跑测试→看报错→再改→直到通过
   Bash 圈在容器 · LLM 只走我们网关（key 不在箱内）· 文件只碰他的卷
   进度经 SDK 消息流 → 我们转 SSE → 前端进度卡片
⑥ CC 收工返 summary；产物（代码）本来就在工作区卷上
⑦ 结果过治理（脱敏/截断）→ tool_result 喂回我们的模型 → 总结 + Canvas 预览
⑧ 「图表改成折线」→ resume 同一 CC 会话再派（上下文还在）

三档分界判据：这段机器工作需不需要「边看结果边改」的自主判断——「涉及文件」不是分界线（1、2 档今天已全部在跑，新增的只有第 3 档）。且两循环不是并列分流量：每轮对话都从我们的循环开始（含重任务），经理常驻、工程师按需雇。

两个卡点解释：① 为什么派而不自己做——编码 = 机器上「读→改→跑→看报错」，需要 Read/Edit/Bash + 4 万行 bash 安全解析 + 打磨两年的编码策略，那是 CC 的核心资产，自己重造 = 搬它最厚的部分，派给它 = 白拿。经理（我们循环：理解需求/拿资源/验收/汇报）× 工程师（CC：自己工位上自主干活）。② 两循环会不会打架——不会：CC 整场工作（它自己几十轮迭代、几分钟到半小时）在外层只是一次异步工具调用（taskId+轮询，delegate_task 同款，并发/超时/tail 治理直接复用）；外层不干涉内层怎么写代码，内层碰不到外层任何东西（连真 API key 都没有）。

再追问：常驻循环为什么不自己做？——诚实前提：能做，且已在做低配版（轻迭代「跑代码→看报错→再跑」今天就会）。第 3 档委派的四笔账：① 差距在行为质量不在循环结构——CC 的资产是两年真实编码任务打磨的行为 + 模型-harness 协同调优；阈值常量抄得走，行为打磨的年限抄不走（数据+评测+迭代次数，非代码量）；② 工具链价码：bash 安全解析 1.9 万行、工具系统 4.1 万行（code-atlas 实测），自建 = 重写 CC 最厚部分且跟不起周更，雇它 = 白拿只付 token；③ 上下文经济学（最实际）：迭代编码烧几十万 token 机器噪音，亲自做 = 噪音涌进用户对话（污染/压缩/账单），委派 = 隔离在 worker 上下文、主对话只收 8000 字符 tail——delegate_task G9 早已承认此原则；④ 边界诚实：门槛是「深迭代时 CC 明显更强」而非「我们不能」，开源编码 agent 达标之日 worker 可换可去。一句话：招工程师不是经理不会写代码——他全球最强且白拿、手艺是年限攒的、让经理亲自写会把会议室变机房。

再追问：「我们的循环也用同款 Claude API，差距真有那么大吗？」——承认：智能在模型里两边共用，差距是「同一台发动机、两副底盘」（实证：同一模型跑 SWE-bench，不同 scaffold 分差十几到几十个点）。⚠️ 2026-07-07 数据修正：该说法对老模型成立、对前沿 Claude 已塌缩——mini-swe-agent（100 行 bash-only）跑 74%+，Opus 4.5 完整 vs 极简 harness 仅差 2.4 点（SWE-agent 官方）；新模型按 agentic 轨迹 RL 训练，「会迭代」已长进权重。Hermes（自研循环）同款 Opus 后端「接近」CC 分数佐证同向。立场更新：雇 Worker 的论据重心从「能力差距」移至「上下文隔离 + 工具链/安全成熟度 + 免维护」——结论不变，论据权重变了；POC A/B 价值更大。同模型下差距三来源：① 工具人体工学+提示纪律（可抄但 = 那 4 万行）；② 训练先验对齐（真护城河）——Claude 在 CC 工具形状上被训练评测，用 CC 直接命中最强编码先验，我们只吃通用先验，且模型-harness 周级协同调优永远慢半拍；③ 长任务上下文纪律（长多文件差距最大、短任务 ≈0）。两个推论：分档边界被精确校准（第 2 档差距 ≈0，差距集中在第 3 档——恰好解释为何只有第 3 档雇 CC）；业务面我们零劣势（先验优势是机器形工具专属，业务工具是我们的形状，模型只有通用先验，CC 来了也一样）。POC 第五测量项：同一编码任务 A/B（我们循环+code_exec vs CC worker，3-5 个难度梯度）——用数据给第 3 档门槛画线。

最终口径 + 注入层三件套（让「可换 Worker」落地）

最终口径：控制面对标 CC 做齐能力；机器形工作全量下放可换 Worker（Claude/Codex/开源）；我们的核心价值 = 身份/记忆/工具的注入层 + 治理收口。「初期其他都给 Worker」的画线：按对话形 vs 机器形切——机器形（含 dev runtime/preview 深化）初期可慷慨下放；对话形（轻业务查询=流量大头、Canvas 文档/图表=流式体验最优、web 搜抓/Teams/cron=基础设施）一个不给。

注入层只对这四个中立接口编程、禁写任何 CC 专属胶水——Worker 即真正可插拔。

业务工具注入不只 MCP：五条路 + Worker 只读原则

跨循环能力供给：Worker 中途要用循环一的业务工具怎么办？

场景真实且常见（迭代任务的本质 = 干了才知道要什么）。机制 = 经理转授三级供给，不是打破隔离：

三级供给
L1 预取（派单时）：数据进文件信箱 ← 覆盖 ~80%
L2 动态只读直连：派单时签发任务级 token（TTL=任务时长 · scope=白名单工具 · 只读）
   Worker 经 CLI/MCP 网关调同一套后端 API
   ← 受控通道复用而非工具移交：RBAC+DataScope 照常强制、照常审计
L3 回调补料：request_from_manager 路由回控制面走完整治理
   （destructive 确认 / ask_user 问真人）→ 结果写回工作区文件
   ← 业务写操作永远走这级；POC 可退化为 requests/*.json + 轮询补料

三要点：① 转授永远是父集合的收窄（同 skill allowed-tools / 子 agent 工具子集原则）；② L1 身份兜底原样生效（任务 token 配宽也越不了权——权限模型铁律第三次兑现）；③ 写操作自动升级为控制面治理事件。

重大输入：Hermes 是我们自己的项目 → 首选 Worker，解开合规死结

不搬 Hermes 循环进控制面：① 几何问题——Python sidecar = R1/R4 否决 CC-as-kernel 的同一拓扑；重写成 TS = 移植设计（已系统性发生：E26 记忆/脱敏/delegate 并发均移植自 Hermes）；② 前提修正——FFAI 循环已是多模型原生，且多了 Hermes 没有的企业侧（其权限/安全 4,758 行四家最少，单用户形态）。

Hermes 当首选 Worker 的解锁：多模型 worker 经我们网关 per-task 路由（合规任务 qwen、硬任务 Claude）→「员工代码发 Anthropic」从二选一变成路由配置题；自己的代码零 license、可原生加 FFAI 适配。Worker 格局：Hermes 为主、CC 为辅，同一注入契约双 worker。POC 升级为 A/B/C 三臂（我们循环+code_exec vs CC worker vs Hermes worker）。

终局修正：论题推到底——自研子循环为默认，Worker 降级为可插拔加速器

收官追问「智能越强、循环越不重要，那干脆不要 Worker、自研循环直接干重活？」——可行，且是最简架构。四笔账在论题下重算：①行为质量已被 mini-swe-agent 打折；②工具链价码本来就不欠——CC 要 1.9 万行 bash 解析因为跑真机，我们跑在可抛弃断网容器，容器就是我们的 bash 安全；③上下文隔离自有方案（delegate_task 子会话 + tail）；④免维护失义。

自研子循环干第 3 档 = OpenAI Codex 形状，比 Worker 更简：delegate_task 子循环 + 机器工具集（容器 exec + 工作区文件，全现成）= 用自有零件拼 mini-swe-agent。容器不装运行时、不开 LLM 出口（network=none 全密封）、注入层归零——LLM 网关/上下文文件生成/任务 token/三级供给全部不需要。

收官问答：模型「知道」要去沙盒执行吗？——不需要知道，信任路径是锁死的

I-33 既有原则：永不信任 LLM 自我约束，约束由结构强制。四层机制，模型认知不在其中任何一层：① 工具清单即世界边界（capability 模型）——列表里不存在「主机执行」这个动作，执行形状工具的实现写死路由进 Docker；② 收口无旁路（I-21）；③ 参数改不了向（orgId/userId 从 ctx 取 + 路径 sanitize）；④ 全错还有爆炸半径（主机唯一 spawn = docker CLI、network=none、可抛弃容器）。类比：柜员不是「知道」不能进金库——他根本没有钥匙，金库还在另一栋楼。system prompt 的工具选择规则是质量优化不是安全边界：提示词是地图，工具实现是物理法则。

09收束论题：能力型 scaffolding 贬值，约束接入型基础设施升值

整场对谈的终稿命题（2026-07-07）——「模型越强、harness 需求越低」的 bitter lesson 主干成立，但只砍掉 harness 的一半。

10依据与终态声明

• 最佳实践依据：企业内嵌 agent 的头部实现（Microsoft 365 Copilot、Salesforce Agentforce、GitHub Copilot 企业版）无一例外自持 orchestration 层、把厂商模型作为可替换后端——「循环自己拿、模型可路由」是企业 ToB 的行业事实标准。Claude Agent SDK 的官方定位是开发者构建 agent 应用的工具链，不是多租户平台内核；CC 自身的单机、单租户、权限弹窗信任模型也从设计上印证它不面向本场景。
• 终态符合性：自建内核 + 设计临摹 + 上游对标是终态方案而非过渡——它是 R1–R5 五条硬约束的唯一解，不存在「以后条件成熟再换回 CC」的隐含计划。唯一的开放项是 §03 的反事实条件与 §04③ 的沙箱内嵌 worker（后者是增量能力）。