COMMUNITY NOTES · AGENT ARCHITECTURES

从 Agents API 到 Grok Bot：一天里群里冒出的五种 Agent 架构

整理自 AKL AI 交流群讨论 · 2026-09-11 · 观点属于参与讨论的成员

9 月 11 日早上 9 点半，Jeff 往群里丢了一条 OpenAI 的链接，配了一句话：

这是极大的突破，这不是模型 API，这是 agent API。 —— Jeff W

接下来的十四个小时，这个群把「Agent 到底该怎么搭」这件事从头到尾翻了一遍。Sunny 发了一份 14 页的 PDF，里面有三个 agent 跑八天的真实账单；HG 看完上午的讨论，晚上交了一份 PostgreSQL 事件驱动的架构图；Tim 抛出一份持续学习引擎的介绍；Arthur 说自己也在关注 Grok Bot，Sunny 回来复核后说「Grok Bot 不是我设想的那个架构」。中间还夹着金的 Codex + Claude 双模型工作流、Jeff 的 governance skill、dingding 推荐的 cross-llm-mcp、XULI 用的 Orca 和 oh-my-pi 的 advisor 模式。晚上十点，RT 把话题拉回地面：新西兰九成以上的企业没有业务流程，「一个月别超过 100，最好免费」。

这些东西表面上都叫「多 Agent」，实际上不在同一层。这篇文章的任务是把它们摆到同一张桌子上，说清楚每一种是什么、解决什么、代价是什么，以及为什么它们可以同时成立。

先立一个坐标系：Agent 系统里的四样东西

不管哪家的方案，拆开都是这四样：

组件	干什么	一句话比喻
模型 (Model)	负责「想」：读上下文、决定下一步	员工的脑子
Harness	包在模型外面的那层：工具、权限、记忆、上下文管理、子 agent、什么时候醒	员工的工位、流程和制度
环境 (Environment / Sandbox)	模型动手的地方：文件系统、终端、浏览器	员工的电脑
状态 (State / Session)	任务做到哪了、产出了什么、下次从哪接着来	员工的工作台账

传统的「模型 API」只卖第一样，剩下三样全靠你自己。今天群里讨论的所有架构，本质上都是在回答一个问题：后三样谁来管，放在谁的机器上，钱怎么算。

把这个坐标系记住，下面五种方案就一目了然了。

一、厂商托管：OpenAI Agents API 与 Claude Managed Agents

Agents API 是什么

Jeff 说得对，它不是模型 API。OpenAI 的原话是：把驱动 Codex 的那套 harness 和基础设施，通过 API 开放给开发者。你一次调用给定任务、模型、工具和环境，OpenAI 负责跑。

它的四个核心对象是：

Agent：模型 + 指令 + 工具 + MCP server
Environment：一台沙箱电脑，可以用 OpenAI 托管的，也可以用自己的
Session：一个持久的工作实例，跨多轮对话保存状态，不用每次重建上下文
Events / Items：你发给它的输入、它产出的输出

Harness 层做了三件今天群里反复提到的事：上下文接近上限时自动压缩（compaction），跨窗口延续工作；tool search 按需加载工具定义，省 token 也保住缓存；子 agent 并行拆解任务，每个子 agent 独立上下文，主 agent 汇总。整个 harness 是开源的 Codex 代码，OpenAI 负责运维和随模型迭代。公测阶段不收平台费，只按 token 和沙箱用量计费。

群里三个判断，逐个对一下

一树空山：「第一感觉就是 MCP，代码里确实写的 MCP。」 半对。Agents API 支持把 MCP server 挂成工具，但它本身不是 MCP。MCP 是「模型怎么接工具」的协议，Agents API 是「谁来跑这个 agent」的服务，两者一个在工具层、一个在运行时层。空山后半句更准：「这不就是大模型厂商拥有云是必要条件吗」，Agents API 的确是把模型和云打包卖。

Jeff：「自带沙箱和上下文，有生存期，不用每次拼凑提示词。还没到 Grok Bot 的程度。」 完全对，这是最准确的一句概括。Session 就是那个「生存期」。至于和 Grok Bot 的差距，下一节讲。

Yuan：「看着和 Claude Managed Agents 差不多。」 不只是差不多。Anthropic 四月上线的 Managed Agents，核心概念也是四个：Agent、Environment、Session、Events，名字都一样。两家在这一层的设计已经收敛：

	OpenAI Agents API	Claude Managed Agents
上线	2026-09 公测	2026-04 公测
Harness 来源	Codex（开源）	Anthropic 自研（闭源）
环境选择	托管沙箱 / 自建 / 九家合作伙伴	托管沙箱 / 自建
自建环境的接法	你在自己机器上跑 `codex exec-server`，它主动向 OpenAI 建 WebSocket 连接，接收指令、回传结果	自建沙箱，同样是你的机器连他们的控制面
多 agent	配置开关，最多并发若干子 agent	支持
计费	只按 token 和沙箱用量	token 之外另按 session 运行时长计费
定时触发	未见明确说明	支持 cron 式定时部署

Tim 对 Agents API 的定位值得记下来。Tim 把 AI 工程产品分了四层：

01AI 工程执行平台

目标执行、Skill、Worker、长程运行、Artifact

02企业研发效能平台

代码任务、测试审查、Workflow / DAG、质量评分、团队协作

03AI 运维与治理平台

事件响应、基础设施巡检、风险预警、自动修复、审批回滚

04可审计自主执行基础设施

Goal Contract、Run Contract、Audit Chain、Completion Gate、租户隔离、Policy-as-Code、Replay 和 Evidence

Tim 的判断是 Agents API「还在第一层，因为它主要还是为了卖模型」。这个判断和空山的「厂商拥有云是必要条件」是同一件事的两面：厂商把 harness 和环境送给你，是为了让 token 流量留在自己家。

一个容易忽略的细节

Agents API 的自建环境模式，是你在自己机器上跑一个执行器，主动连出去，听云端 harness 的指令干活：改文件、跑命令、调本地 MCP。这和 Sunny 八月底分享的 Raft 是同一种拓扑：本机 daemon，云端 server。Sunny 在 PDF 里提的那个问题，对 Agents API 同样成立：daemon 拿着本机 shell 权限，指令来自网络上的 server，「server 在云端还是自己机器上，是两种不同的信任模型」。厂商托管方案并没有绕开这个问题，只是把 server 换成了 OpenAI。

二、产品化的常驻同事：Grok Bot

Arthur 上午说「我也在关注 Grok Bot」，Sunny 随后回复：

我回来复核了，Grok Bot 不是我设想的那个架构。 —— Sunny

为什么不是？先看 Grok Bot 是什么。

xAI 今年八月上线的 Grok Bot，面向的不是开发者而是终端用户。它的对象也是五个：Bot（一个有名字的常驻 agent，官方说法是「一个 AI 队友」）、Chat、Prompt、Tool、Artifact。关键设计有三条：

每个 Bot 跑在一台持久的云端虚拟机上，有浏览器、文件系统和终端。你关掉笔记本它继续干。
你名下所有 Bot 共用同一台云电脑，记忆、文件、浏览器登录态跨轮次保留，Bot 之间交接不用重新配置。
Bot 之间可以互相发消息、在群聊里共享上下文、移交任务；Routines 让 Bot 按时间表或事件自己开工，不用等你发指令。

对照 Agents API：Agents API 给你 Session 这个「生存期」，但 Session 是围绕一个任务的；Grok Bot 给你的是一个有名字、有记忆、有日程、能和同事群聊的角色。Jeff 说 Agents API「还没到 Grok Bot 的程度」，差的就是这一层：从「一次任务的运行实例」到「一个常驻的同事」。

Sunny 为什么说这不是自己设想的架构？看 PDF 最后两页就明白了。Sunny 的设想是算力和状态留在自己手里：家里的工作站、办公室的 NUC、朋友的 GPU 机器各跑本地模型，注册到同一个频道和任务板上领活，云端顶级模型只在裁决点介入。Grok Bot 正好相反：算力、状态、记忆全在 xAI 的云上，你只是租了一群同事。方向一致（常驻、有记忆、能协作），但「东西放在谁家」这个根本问题上，两者是两个极端。

三、自建派 A：Sunny 的网状架构，以及那份账单

Sunny 的 PDF 标题叫《从管网络设备到管一群 Agent》。Sunny 是传统网络工程师出身，需求很具体：一个跨天、跨周的 coding 项目，三台电脑、多个订阅账号、四种模型（Fable、Opus、Codex、Kimi），每家 CLI 的 subagent 都出不了本进程、本账号。

Sunny 现在跑的架构：云端一个 Raft server 做频道和任务板，三台机器各跑常驻 daemon。角色分工写得很清楚：

角色	做什么	不能做什么
人（持有人）	定任务、授权、验收	—
CEO · 云端顶级模型	拆解、排序、派发、复核、裁决、合并	不写业务代码，不跑测试，不替人决定
裁决者 · 另一家模型	独立复核与裁决	不写代码，不提交
实现者 · 若干	实现、实测、写报告	不碰别人的 lane
后备	某个 agent 达限时接管	继承同样的限制

agent 之间没有直接对话，全靠频道消息和任务状态衔接：待领 → 进行中 → 待审 → 完成 / 打回。

它跑通了。 早上起来任务卡在动，PR 在合并；agent 之间能互相纠错，Opus 证明过 CEO 写的验收判据对目标那一层是盲的，CEO 复核后改了判据。用 Sunny 的话说：「网状这条路是通的。问题出在别处。」

问题在账单。这是全天讨论里最硬的一组数据，来自 Sunny 本机三个 agent 从 9 月 1 日到 9 日的会话记录：

Agent	API 调用	输出 token	重复读取的上下文	每次调用携带的上下文
CEO · Fable 5.1	17,284	17.1 M	8,873 M	≈ 513 K
Opus 5	15,612	13.5 M	7,911 M	≈ 507 K
Sonnet 5	6,188	3.4 M	3,301 M	≈ 533 K
合计	39,084	34.0 M	20,085 M

三个 agent 八天，真正干活的输出 3400 万 token，重复读取的上下文 200 亿。输出只占总量的 0.2%。 Arthur 中午把这句话单独拎出来发到群里：「这是重点，也是很多人会走的弯路。」

钱花在哪了？agent 常驻，就要不停轮询「有没有新消息」；每次轮询都是一次完整 API 调用，带着 50 万 token 上下文；一天几千次，绝大多数什么都没发生，账单照走。缓存读取便宜，但便宜乘以 200 亿也不便宜。连锁反应跟着来：Codex 账号撞用量上限下线，其他 agent 干等；Fable 被安全护栏静默降级到 Opus 4.8，一周没人发现；几个订阅账号轮流耗尽。

Jeff 补了一个经验数字：「每输入一个 token，实际给模型的至少是 5 个 token 的提示词，里面是各种上下文和 agent 自己写的提示词。这个比例在持续增长。各模型公司收你的 token 费，实际上大多数是 agent 自己消耗的。」

归因：harness 的问题，不是模型的问题

Sunny 的结论是这次讨论的分水岭：模型本身没错，错的是包在外面那层机制。没人管三件事：

01什么时候该醒

事件驱动，还是轮询

02醒了看多少上下文

全量携带，还是按需装载

03什么事值得用什么模型

一律顶配，还是分层

而写在提示词里的协作规则是软约束：会忘、会丢、没重试、没超时。

Sunny 的设想因此是把「生产 token」和「做决定」分开：本地硬件 + 开源模型负责轮询频道、读日志、跑测试、样板代码、第一轮 review，这些高频、低价值、可重试的活，token 几乎免费；云端顶级模型负责拆任务、定方向、仲裁分歧、最终验收，低频、高价值、不可重试。Sunny 的类比：「本地模型是员工，云端模型是管理层。管理层不该每十分钟刷一次群。」

再往前一步就是「算力池」：Raft 和 Multica 的 runtime 都能接本地推理服务（Ollama、vLLM），把地理位置不同的机器注册到同一个 server，就是一个虚拟算力集群。Sunny 在群里举的例子：「假定 Arthur 家有一个 DGX Spark，可以注册到一个资源池；我有一个 Mac Studio 跑本地大模型，也注册进去，这样我的 token 资源可以和 Arthur 的共享。」Jeff 的反应是「资源池这个好，我已经迫不及待想用了」。

PDF 里自己列的待验证项也很诚实：跨地域延迟对协作节奏的影响；异构模型的输出质量怎么对齐；谁来调度、怎么防止重复领任务。

四、自建派 B：HG 的 PostgreSQL 事件驱动架构

HG 晚上八点半发的 PDF，开头一句话是「今天上午看大家讨论，我按自己的理解整理了一个简单的多 Agent 协作架构」。有意思的是，它几乎逐条回答了 Sunny 归因出来的三个问题。

核心思路一句话：Agent 通过 PostgreSQL 共享任务、状态和事件，通过对象存储共享运行产物，通过 Git 管理代码版本；上下文按需加载。

三台机器，三个角色（研究 / 开发、分析 / Review、写作 / 测试），可以跑不同模型。它们不互相说话，都连同一个 PostgreSQL。

三种东西，三个地方

这份架构最清楚的一点是把「状态」「产物」「代码」分到三个存储里，各有明确的适合与不适合：

存储	存什么	不存什么
PostgreSQL	tasks（要做什么、谁的、状态）、events（发生了什么、叫醒谁）、artifact 元数据（路径、摘要、版本、hash）、decisions（审批、失败原因、重试次数）	完整 PDF / 图片、agent 的完整聊天历史、源代码文件
对象存储（NAS / MinIO / S3）	原始资料、research.json、analysis.json、draft.md、final.pdf、必要的运行日志	任务调度状态、可靠事件队列、源码版本
Git	Worker 源代码、Dockerfile、PR、commit SHA、CI/CD	运行产物

数据库里只存「指针 + 摘要 + hash」。一个 artifact 记录长这样：object_key = reports/project_27/analysis.json，summary = "6 key findings, 2 uncertainties"。Agent 被叫醒时先看这一行摘要，再决定要不要下载整个文件。

「快递柜 + 手机提醒」

跨机器怎么叫醒下一个 agent？HG 用的是 PostgreSQL 自带的 LISTEN / NOTIFY：

01Agent A 完成任务

产出 artifact

02同一个事务里

UPDATE tasks SET status='done' 并 INSERT INTO events (TASK_COMPLETED, target=B, pending)

03NOTIFY task_events 发一条轻量提示

只带 event_id

04Machine 2 上一个普通 Python 进程平时阻塞在 LISTEN，收到才醒

醒之前不调 LLM

05Agent B 查 event 和 task，按 artifact key 只读需要的文件

最后才调 LLM

为什么有了 NOTIFY 还要 events 表？因为 NOTIFY 不是可靠队列。Machine 2 关机时 A 已经写进 events，但 B 没收到提醒；B 重启后先查一遍 status='pending' 的事件补上。HG 的比喻：「events 表是快递柜里的包裹，NOTIFY 是手机提醒。」通知丢了不等于任务丢了。

代码变更走另一条线：push / PR / merge 触发 GitHub Webhook，一个接入服务验签解析出 repo、branch、commit SHA 写进 repo_events，Reviewer agent 按 SHA checkout，保证不同 agent 看到的是同一个版本。

对着 Sunny 的三问

Sunny 的问题	HG 架构的回答
什么时候该醒	阻塞 LISTEN，有 NOTIFY 才醒，无事件不调 LLM。轮询没了
醒了看多少	先 task + summary，再按引用加载必要 artifact 或代码，只有需要时才读原始 PDF 和完整日志。不加载整段聊天历史
什么事用什么模型	每台机器可以跑另一种模型，任务类型决定路由

HG 自己标注的适用范围：「少量 Worker、多台机器、需要简单、可审计、低成本的多 Agent 协作。」什么时候升级到 Redis Streams / RabbitMQ / Kafka？「当需要更高吞吐、多个消费者组、复杂重试 / 死信、削峰、跨服务解耦时再升级。Agent 只有几台机器和少量 Worker 时，PostgreSQL 方案通常更省事。」

Sunny 的评价：「我认为这也是一个思路，但是是纯软件的，思路可以相互借鉴。」两人的差别在于：Sunny 用现成的 Raft / Multica 当频道和任务板，把力气花在角色设计和算力分层上；HG 不引入第三方 agent 平台，用数据库、对象存储、Git 三件老工具自己搭一遍。一个买，一个造。金看完说「我基本上也是这么做的」，HG 回：「你这个已经是实际在跑的方案了，我这边更多是从架构角度整理。」

五、自建派 C：Tim 的持续学习引擎

Tim 的方案在另一个维度上。前面四种回答的都是「agent 之间怎么协作」，Tim 回答的是「系统怎么从跑过的任务里变好」。

Tim 上午的自述值得完整引用：

我是做了我自己的 harness 工程，所有的都是留在本地，有自己的 memory、自己的 Loop、自己的并行任务、本地的知识库。LLM 是我的一个能力接口，已经做到跟 LLM 无关了。然后还有长程执行和持续学习。 —— Tim

晚上发的 PDF《NextLoop Continual Learning Engine》是 10 页图片，讲的是这个 harness 里的持续学习模块。核心组件五个：

01轨迹收集器

每次交互生成标准化 Trajectory 对象，带任务类型、模型 ID、得分、遥测；滑动窗口缓存最近 N 条，持久化存储

02归因路由器

从轨迹里识别失败模式，把信号路由到四个子系统之一（Harness / Model / Memory / Healing），带置信度评估，为每个目标生成具体改进操作

03四路并行优化

提示词优化器（约束强化、上下文感知、示例驱动）、技能合成器（从成功轨迹合成新技能）、子代理进化器、记忆巩固器

04验证门禁

Acceptance Gate（新任务 ↑ 旧任务 ↔ 回归 ↓ 成本 ↓ 四闸门闭环）→ Behavioral Drift Gate（五维行为差分，策略 / 风险是硬红线）→ Canary Check（真实 benchmark 上验证）

05自愈系统

健康探针 → 故障诊断 → 自动修复 → 效果验证

用前面的坐标系看，Tim 做的是把 harness 本身变成一个可以自我修改的对象，而且修改要过门禁，防止「改进」变成退化。这和 Sunny 说的「harness 需要根据自己的实际情况慢慢磨」是同一件事，只是 Tim 想让系统自己磨。

Tim 也承认自己「跑偏」：「总是想着如何将 AI 纳入企业现有的 IT 基础架构中去，参与企业的业务流程并赋能。」Tim 在国内做了近二十年 BPM，晚上贴了一张 Jade BPM 的平台架构图，想把 AI 能力通过应用集成方式加进去。这条线的现实检验放在最后一节。

六、轻量派：不养基础设施的人怎么办

Sunny 的 PDF 里有一页叫「这种 harness 符合大多数人的工作流吗」：大多数人的日常是打开一个 CLI，做一件事，关掉；一个进程内的 subagent 就够了，用不到 daemon、频道、任务板。网状的每个优点都是用运维成本换的。

群里当天出现的几种轻量做法，正好覆盖了这个区间：

文档沟通。 Jeff 的做法是「自己写了个 governance skill 协调 Claude、Codex、Cursor，全部通过文档沟通，性能有一些问题，不过够用」。金的主工作流也是这个形状：你和 ChatGPT 讨论产品与架构 → MD 文档形成唯一真相 → Claude Code 做 Plan / 架构 / 验收 → Codex 实施 → Claude Code 再次审查 → 你批准 commit / push。金上午抱怨「ChatGPT 和 Codex 也不互通，不能接到 Claude Code，我就来回截图」，中午自己找到了解法：Codex 现在也调用 Astra，可以设 1M 上下文，直接在 Codex 里搭头脑风暴工作流，「你提出想法 → Codex 读取设计资料并与你讨论 → Claude 提供独立意见 → 你选择方向 → Codex 整理 MD → 原有生产流程按需接收」。dingding 提醒了一句：外置共享文档「上下文可能会 grow 得太快」。

cross-llm-mcp。 dingding 推荐。一个 MCP server，把 ChatGPT、Claude、Gemini、DeepSeek、Kimi、Grok 等九家模型包成工具，在任何 MCP 客户端里一次调多家。解决的是「在 Claude Code 里问一句 GPT」这种最小需求。

Orca。 XULI 在用，「agent 可以派 worker，上下文可共享」。Orca 是 Stably AI 开源的 Agent Development Environment，基于 Git worktree 给每个 agent 隔离的并行运行环境，支持三十多种 CLI agent，上面一层 orchestration skill 负责一个 lead 派任务、等结果、需要决策时通知你手机。XULI 也说了它的边界：「有时也不好使，比如碰上 freebuff 这种另类小众 vibe coding 平台。」

oh-my-pi 的 advisor 模式。 XULI 提的「高低搭配」：「干活的 agent 跑着，advisor 旁边看着插话，干活 agent 可能被及时矫正回来。」oh-my-pi 的 advisor 用自己的模型、自己的上下文，读主 agent 的每一轮，往里插一句提醒、担忧或者硬阻断；它不批准动作、不改主会话状态。这是 Sunny 方案里「裁决者」角色的单机版。

厂商自己也在填这个坑。 金那张 ChatGPT 截图里，ChatGPT 的回答是 OpenAI 已经提供了 Codex 的 Claude Code 插件，可以直接在 Claude Code 里委派任务给 Codex、取回结果，用本机已有的 Codex 订阅登录，「不是新的 Agents API，但可能更直接地解决你现在来回复制粘贴的问题」。

七、把五种方案摆到一张表上

	Agents API / Managed Agents	Grok Bot	Sunny：Raft 网状	HG：Postgres 事件驱动	Tim：NextLoop
面向谁	开发者	终端用户	自己	自己	自己
Harness 谁管	厂商	厂商	Raft / Multica + 提示词里的规则	自己写的 Python worker	自己写，且能自我修改
模型跑在哪	厂商云	xAI 云	云端 API + 设想中的本地池	每台机器自选，可本地	本地为主，LLM 是可替换接口
环境在哪	厂商沙箱或自建执行器	xAI 云 VM（所有 Bot 共用）	三台本机 daemon	三台本机	本机
状态在哪	厂商的 Session	xAI 云（记忆、文件、登录态）	Raft 云端 server	自己的 PostgreSQL + 对象存储	本地 memory + 知识库
怎么醒	你发事件	你发消息，或 Routine 定时 / 事件	daemon 轮询频道（问题所在）	LISTEN / NOTIFY，无事不醒	自己的 Loop
跨模型	单家	单家	四家混编	每台机器自选	LLM 无关
人在回路	发事件、打断、steer	群聊里像同事一样	频道里改方向、否决、验收	创建任务、审批、驳回	—
付钱方式	token + 沙箱（Claude 另按 session 时长）	订阅	多个订阅轮流撞上限	云 token 或本地电费	本地电费 + 少量云 token
运维成本	几乎为零	零	server + 三台 daemon + 账号	数据库 + 对象存储 + worker	整套自研
代码和数据出不出家门	出（自建执行器时文件留在本机，但模型读到的内容仍经过厂商云）	出	代码不出本机，消息和任务状态经过云端	全部在自己手里	全部在自己手里

看这张表有两个规律：

越往左，越省事，控制权越少。 厂商托管把 harness、环境、状态三样全拿走，你只剩下写任务。Grok Bot 更进一步，连「开发者」这个身份都不需要。代价是所有东西都在别人的云上，计费单位是别人定的。

越往右，控制权越多，越要自己养。 HG 把三样东西全放在自己手里，代价是数据库、对象存储、worker 都是自己的运维。Tim 更往右，harness 本身都是自研的。

Sunny 在中间：用现成的 Raft 当组织层省了搭 server，但状态在别人手里；设想中的本地算力池又想把模型拉回自己家。Sunny 自己列的第一个讨论题就是「本地硬件投入 vs 订阅费，多大规模才划算」。

八、贯穿全天的两条线

token 经济学

从 Sunny 的 0.2% 到 Jeff 的「五倍提示词」，再到下午那段财务报表识别的插曲，全天有一条暗线：什么活该用大模型，什么活不该。

下午有位群友问，用 Codex 抽取图片里的企业财务数据（试算平衡表），MinerU 能转对 80%，剩下 20% 出错，有没有推荐的 skill。几个人的回答方向一致：

Sunny：「这不是某个 skill 能解决的问题。首先你需要站在你的角度考虑你的原数据 AI 是否能看懂。AI 现在是吃细糠的主，比较挑食。」
Yuan：加预处理，把大图切成多张、删掉空白、把三列拼近一些；「把问题描述清楚告诉 agent 应该都能帮你做成固定流程。牺牲灵活性换取准确性。」
XULI：换个开源 Python 项目，agent 不行的时候加 Python 程序，「还要加上 Python 加总校验」。
满天星：表格识别用 Gemini 或 GLM 的 OCR 小模型，「Codex 其实不适合，大模型的多模态端一般会压缩分辨率」；逻辑适合让 Codex 写。
一树空山：「图片信息提取要本地做，AI 在准确性和速度上都没有本地好。」

这段和上午的架构讨论是同一个道理：大模型是管理层，不该让它去干 OCR 和加总校验这种员工的活。Sunny 中午那句总结适用于两边：「干活的 token 消耗就给本地大模型，反正只消耗电费、硬件磨损。」

新西兰的现实

晚上十点，Tim 说自己「总是想着如何将 AI 纳入企业现有的 IT 基础架构」，RT 接了话：

新西兰中小企业的 AI 应用场景只能通过 SaaS 来完成，不存在任何第二种模式，至少三年到五年内。新西兰百分之九十以上的企业没有业务流程，这里边一半以上的架构部门都不存在，小老板们自己都干了。小老板们百分之五十的时间是在救火和扯皮。大厂那套玩意儿在新西兰行不通，水土不服。一个月别超过 100，最好免费，否则没人买单。 —— RT

Roland 从另一个角度补了一句：「其实到最后是降低用户学习成本和使用难度。有很多很好的产品，但是因为学习难度太大了，导致用户没办法用下去。」Jeff 的结论是「小工具估计是新西兰大多数企业可以接受的方式，或者服务类，就是 contractor」。Tim 最后自己总结成六个字：「开箱即用 + Contractor。」

把这段放在架构文章的结尾，是因为它决定了前面七节的读者是谁。今天讨论的五种架构，从 Agents API 到 NextLoop，服务的都是「自己就是工程师、自己养自己的 agent」的人。RT 描述的那九成企业，需要的是把这些东西藏在一个月 100 块以内的 SaaS 后面，或者一个上门的 contractor 手里。Tim 的四层模型里，第一层是卖给工程师的，第二到第四层才是卖给企业的，而新西兰的企业大多连第二层的前提（有流程）都没有。

术语表

Harness: 包在模型外面的整套机制，包括工具、权限、记忆、会话管理、子 agent 机制、唤醒策略。Sunny 的原话：「这一层决定了 token 怎么花。」
Session: 一个 agent 的持久工作实例，跨多轮保存状态。OpenAI 和 Anthropic 都用这个词。
Environment / Sandbox: agent 动手的地方，有文件系统、终端、浏览器。可以是厂商的，也可以是你自己的。
Compaction: 上下文接近上限时自动压缩早期内容，保留继续工作所需的信息。
MCP: Model Context Protocol，模型接工具的协议。Agents API 支持挂 MCP server，但 Agents API 本身不是 MCP。
LISTEN / NOTIFY: PostgreSQL 自带的轻量发布订阅。NOTIFY 发提示，LISTEN 阻塞等待。不是可靠队列，所以要配一张 events 表。
Artifact: agent 的产出物，如 research.json、draft.md、PR。HG 的原则是文件放对象存储，数据库只存指针、摘要和 hash。
Advisor: oh-my-pi 里的旁观者角色，用独立模型和上下文读主 agent 的每一轮并插话，不批准、不改状态。
Routine: Grok Bot 里按时间表或事件自动启动的任务。
Daemon: 常驻在本机的守护进程，负责启动 agent、转发消息。Raft、Multica、Agents API 自建环境模式都靠它。

接下来

一树空山上午提议「给我们搞一个技术沙龙讲讲」，Arthur 说「Jeff 和 Tim 可以讲，我负责找场子、后勤」，还点了 Sunny 和空山的名。Tim 说「群里这么多大佬，我就是自己闲来手搓」，Sunny 说「烧真金出来的」，金建议腾讯会议直播。

场地还在找。Sunny 留给大家的三个问题，也是这场沙龙最好的议程：本地模型怎么选、怎么测；本地模型生产的 token 能干活吗，质量和效率怎么样；这是少数人的需求，还是大家迟早都会遇到的需求。

如果你有「一个 session 装不下、一台机器不够」的时刻，或者正好相反，觉得这套东西过度设计，带着你的具体搭法来。从这里加入 →

参考资料

OpenAI, Introducing the Agents API（2026-09）
OpenAI Developers, Agents API overview / Self-hosted environments
Anthropic, Claude Managed Agents overview
xAI Docs, Grok Bot overview
Sunny Zhang,《从管网络设备到管一群 Agent》（多 Agent 编排分享，2026-09）
HG,《简单多 Agent 协作总体架构》（multi_agent_postgres_event_architecture.pdf）
Tim,《NextLoop Continual Learning Engine v10.7.0》
社群笔记《多 Agent 编程，星状还是网状？》aklaiclub.co.nz/multi-agent