构建信号SIGNAL TO BUILDEnglish站主登录 ↗
← 知识整理
AI 技术与工程 ／ 知识整理 · 中英版本

AI Agent 架构与多 Agent 编排(跨作者主题综合)

6+ 视角的 AI Agent 架构融合。黄益贺(Workflow / Agentic Workflow / 5 大特征 / Chief-Deputy-Specialist / Agent Native 预测)/ newtype 研究报告(4 大编排模式 + Google ADK 8 模式 + MemoryOS 3 层 + 6 大框架对比)/ 王凯(字面"终端窗口即 Agent" + 身份×工种矩阵 + cdp-proxy 隔离 + Agent 分级 L1-L5)/ AWS Agent 4 篇(idoubi / ANP 协议 / Reasoning Model)/ Agent 论文 3 篇(CAMEL Scaling Laws / More Agents Is All You Need / ChatQA)/ Codex/Cloud Code(lenny)/ 深思圈 VC 视角。覆盖 Manus 评价分歧、Sub-Agent 哲学、Workflow vs Agent 命门、生产部署案例

资料来源：跨来源主题整理 · 本站发布：2026-09-26 · 笔记更新：2026-10-18

Agent 架构多 Agent 编排记忆系统

何时打开:你要做 Agent 产品 / 写 Agent 技术方案 / 选 Multi-Agent 框架 / 给老板讲清"Agent 这赛道"。本 wiki 把 9 份 author wiki 在 Agent 架构主题上的不同视角(帖子级判断 + 研究报告 + 实操架构 + AWS 讲座 + 论文 + Anthropic/OpenAI 内部 + VC)抽出共识和显式分歧。

一句话核心:"Agent" 在不同作者那里指的不是同一件事 —— 你必须先确认你在哪一层(单 Agent 工程化 / 多 Agent 编排 / 多终端矩阵 / Workflow + 关键节点 Agent),否则跨作者的方法论不能直接拼接。

0. 5 重视角的"Agent / Multi-Agent"是什么?

视角 来源 "Agent"指什么 编排单位
帖子级判断派 newtype · Agent 架构与多 Agent 编排(黄益贺) 感知 + 自主决策 + 执行动作(时间展开的动态体) Chief / Deputy / Specialist 三层
研究报告派 AI Agent 技术架构演进 2025(深度研究报告) 企业级基础设施(Morgan Stanley 98% 采用) 4 大编排模式(Supervisor/P2P/Hierarchical/Event-Driven)+ Google ADK 8 大基础模式
矩阵化实操派 王凯 Agent 工程实操 / 王凯多 Agent 浏览器矩阵架构(v1.1 实操指南) 字面意义"开一个新终端跑 claude" 身份(Identity) × 工种(Role)矩阵 / cdp-proxy + sessionId 隔离
AWS 行业实战派 AWS Agent 系列讲座 2025(4 篇汇编) Agentic AI 4 要素 + 段位 3 级(王晓妍) Reasoning Model + Multi-Agent Orchestrator(汪其香) / ANP 协议(常高伟)
论文学术派 Agent 研究论文 3 篇精读(2024-2025) CAMEL: # Agents 取代 # Parameters More Agents Is All You Need: sampling-and-voting 暴力堆数量
Anthropic/OpenAI 内部 Lenny's Newsletter / 2026 AI 时代组织运营三人谈(Anthropic + OpenAI) Software Engineering Teammate(Embiricos)/ Coding Agent + Cowork(Cat Wu) Mixed-Initiative(混合主动)+ Compaction(关键创新)

关键观察:这 6 派对"Agent"的定义跨度极大 —— 从"逻辑结构的动态决策体"(老黄帖子级判断)到"开一个新终端"(王凯字面用法)再到"# Agents 取代 # Parameters"(学术论文)。不要混用方法论而不澄清前提。

1. 跨作者共识(7 条)

1.1 Agent ≠ Workflow,两者相辅相成(不是替代)

newtype · Agent 架构与多 Agent 编排 §0 给的核心定义:

Workflow Agent
本质 定义任务及任务间的依赖关系 感知环境 + 自主决策 + 执行动作
形态 流程图 / 蓝图(静态) 时间展开的一系列动作(动态)
核心 依赖关系 决策与执行
侧重点 "做什么 / 按啥顺序做" "此时此刻该怎么办"
抽象层次 高(业务流程) 低(执行智能)

老黄的最终判断:一项工作 = 空间结构(Workflow)+ 逻辑结构(Agent) —— 落地方式是 Agentic Workflow(骨架 Workflow + 关键节点 Agent)。

王凯实战印证(王凯 Agent 工程实操):"互联网时代有 cron / 定时任务,但都是预写规则;AI Agent Loop 是有判断能力的循环"。

研究报告(AI Agent 技术架构演进 2025(深度研究报告)):4 大编排模式都是 Workflow + Agent 的组合,不存在"纯 Agent"的生产部署。

1.2 Multi-Agent 命门是 Workflow 设计,不是模型/Prompt

老黄(newtype · Agent 架构与多 Agent 编排 §1 / 2024-04 帖 69)最早最关键的判断:

"搭建 Multi-Agent System 在技术上一点都不难。难的是你得想清楚,你想让 Agent 怎么做。"

Why 这是 90% 项目失败的根因:

  • 多数团队卡在"训模型 / 调 Prompt",不在 Workflow 设计上花心思
  • 没有 Workflow,Agent 就是个能聊天的玩具,没法持续产出
  • 业务理解才是 Multi-Agent 的真护城河,Prompt 工程是浅层

王凯亲历印证(王凯 Agent 工程实操 §9):"AI 陷入到优化细节,跳不出来说'清仓保现金'" —— 6 个大模型给币圈 1 万美金自主决策实验,所有模型都困在当前持仓的细节优化里,纯自主决策必须有"清仓"权限,否则永远陷在细节优化中。

研究报告印证:Google ADK 团队总结的 8 大基础模式(Sequential / Parallel / Loop / Router / Fork-Join / Map-Reduce / Reflexion / Hierarchical Plan-Execute)都是 Workflow 级别的编排,不是"让 Agent 自由发挥"。

1.3 Agent 交付率 3 法则(老黄给的判断框架)

newtype · Agent 架构与多 Agent 编排 §5(2026-01 帖 2208):

法则 内容 本质
1 任务明确 减法:边界要紧
2 场景封闭 减法:不能让 Agent 在无限开放世界乱跑
3 结果可验证 闭环:必须有自动化方式验证 Agent 输出对不对

核心洞察:

"通用 Agent 的陷阱是,试图在一个无限开放的世界里解决模糊问题。然而,目前 AI 的能力还是概率性的。要得到确定性的产品交付,就必须人为限制搜索空间。"

王凯印证(王凯 Agent 工程实操 §10):"可验证性 = AI 优势区,不可验证 = AI 弱区"(引 Jason Wei 论文)。

场景 适用度 原因
编程 ⭐⭐⭐⭐⭐ 结果可验证(跑通就对)
投资决策 ⭐⭐⭐⭐ 结果可验证(赚钱就对)
数学题 ⭐⭐⭐⭐⭐ 有标准答案
内容生成 ⭐⭐⭐ 主观评判,易飘
市场调研 ⭐⭐⭐ 信息源严重影响质量
法律 / 医疗 ⭐⭐ 准入 + 风险高

1.4 通用 Agent 长期被模型升级吃掉(Manus 命门共识)

老黄(newtype · Agent 架构与多 Agent 编排 §6 / 2025-03 帖 941)当面 diss Manus:

"如果你过去半年高频用 Claude / Cursor / Deep Research,看到这种拆解需求 / 搜集信息 / 调用工具的做法,不会感到震惊,只是微微一笑。所有基于模型的修修补补,都将被模型能力升级而覆盖掉。没模型,只能昙花一现。"

王凯印证(王凯 Agent 工程实操 §8):"Manus 国内首款相对复杂,但门槛不高 / 本质是 token 消耗变多"。

典型例子:GPT-4 自带 Browser → 替代了很多 Browser Use 类产品;Claude Code 自带 Sub-agents + Skills → 替代了很多通用 Coding Agent 包装。

1.5 CLI 比 GUI 强 10 倍(对 Agent 而言)

老黄(newtype · Agent 架构与多 Agent 编排 §4 / 2025-07 帖 1461):"命令行 Agent + 成熟的 MCP 生态 = 通用 Agent 骨架"。

CLI(对 Agent 友好) GUI(对 Agent 不友好)
输出 文本/JSON,Agent 直接消化 像素,Agent 要先 OCR
组合性 Unix 几十年的管道 / stdin/stdout 点击模拟,慢且脆
并发 批处理 / 并发 / 失败重试 一个窗口一次

王凯实战印证:终端窗口即 Agent / Chrome MCP 控制真实浏览器 / 飞书 CLI 拉文档 / 自建金融 MCP。

老黄 2025-10 反思(newtype · Agent 架构与多 Agent 编排 §3 末):newtype OS 自己就彻底 CLI 化了。不是 To Human,而是 To Agent。

1.6 MCP 是当前事实标准(2024-11 Anthropic 推 → 2025 全行业接入)

AI Agent 技术架构演进 2025(深度研究报告) §四 + newtype · MCP 协议与生态实战:

  • 2024-11 Anthropic 推出 MCP(Model Context Protocol)
  • 2025 年成为事实标准,OpenAI / Anthropic / Google / 6 大框架全部接入
  • 解决"工具调用每家自定义协议"的混乱

王凯 MCP 实战清单(王凯 Agent 工程实操 §3):

  • FMP MCP(金融数据)— 解决 AI 联网搜索拿数字编造的问题
  • Chrome MCP(改造支持用户数据 + session 复用)— 多 Agent 并行控制不同浏览器
  • 飞书 CLI(Agent 间协作总线)
  • AgentMail(Agent 专用邮箱)

详见 MCP 协议生态(跨作者主题综合)。

1.7 真正多 Agent 编排 5 大特征(老黄判断标准)

newtype · Agent 架构与多 Agent 编排 §7(辨析"Claude Code Sub-agents 不算真正的多 Agent 编排"):

# 特征 内容
1 层次化与嵌套编排 支持 meta-orchestrator 管理子 orchestrator(团队中的团队),允许复杂委托链 + 辩论/审核机制
2 多模型 / 跨提供商 不同 Agent 用不同模型(Opus 规划 / Flash 执行 / Grok 搜索),优化成本/性能
3 共享状态与高级协调 持久记忆 / 冲突解决 / 动态路由 / 循环迭代 / 错误恢复,由外部代码或框架管理
4 真正并行与扩展性 支持数十甚至数百 Agent 并发,适用于长运行 / 大规模任务
5 开源 / 可编程灵活性 开发者用代码定义 workflow,不依赖单一 LLM 的"自然语言委托"

Claude Code Sub-agents 的实际地位:"内部任务路由 + 轻量委托" / "入门级,只适合简单场景"。

王凯 5 大特征实战印证(王凯多 Agent 浏览器矩阵架构(v1.1 实操指南)):

  • 层次化 ✓(身份级共享 + 工种级 agent)
  • 多模型 ✓(Claude Code + Codex CTO 审查)
  • 共享状态 ✓(身份级 .config / cdp-proxy sessionId)
  • 真正并行 ✓(单身份 N 个 agent + 多身份并行)
  • 开源/可编程 ✓(独立终端 + .mcp.json + CLAUDE.md)

2. 显式分歧(4 条 —— 不抹平)

2.1 分歧 1:Agent = "Task tool 启动子"还是"独立的真实终端"?

这是 Claude Code 工作流(跨作者主题综合) §2.2 已经标注过的分歧,在多 Agent 主题里更明显:

视角 立场 "Agent"指什么
老黄 newtype Profile(newtype · Agent 架构与多 Agent 编排 §8) Chief / Deputy / Specialist 三层 内部 sub-agent / Task tool 启动的子 Claude Code
王凯(王凯多 Agent 浏览器矩阵架构(v1.1 实操指南)) 身份 × 工种矩阵 字面意义"开一个新终端、跑一次 claude 命令"
研究报告 4 大编排模式 Supervisor / P2P / Hierarchical / Event-Driven 通过 LangGraph / CrewAI / AutoGen 启动的逻辑 Agent
AWS 汪其香 Reasoning Model + Multi-Agent Orchestrator 独立编排器调用各 Reasoning 模型

真分歧:他们说的"Agent"不在同一层:

  • 老黄 / Cal Rueb / 研究报告 = 逻辑 Agent(模型实例 + 工具集 + 角色定义)
  • 王凯 = 物理 Agent(真实独立 OS 进程 + 真实独立浏览器 + 真实独立账号)
  • 论文 CAMEL Scaling Laws = # Agents 当变量(单个模型 + 多次 sampling-and-voting)

互补结论:同时存在 3 层架构:物理 Agent(王凯) > 逻辑 Agent(老黄)> 采样 Agent(论文)。前者可以承载后者,但反过来不行。

2.2 分歧 2:Agent 是新创业方向 还是 模型公司必吃的下一代功能?

视角 立场
老黄(2025-03 帖 941) 避开通用 Agent 赛道 —— 在 OpenAI / Anthropic / Google 三家碾压下活不下来
王凯(2025-03-29) Agent 不是创业方向(小微 team) —— "token 单次成本太高 / 大模型公司自己做 / 生态完善前竞争是赔钱战"
王凯(2026 矛盾立场) 但"Agent 周边机会很多" —— 使用模板库 / Agent 导航 / 精选案例 / 垂直 Agent
研究报告(2026-01 视角) 企业级部署已成熟 —— Morgan Stanley 98% 采用 / Klarna / BBVA / Rakuten
AWS idoubi 独立开发 10+ AI 产品 + 一小时上线 SOP —— 包通用 Agent 一层串起来满足细分场景
深思圈 VC 视角(深思圈作者全集入口) Agent 估值狂热(69 篇含 "Agent")—— a16z / 红杉持续投

真分歧:这不是"对错"之争,是市场分层不同:

  • 创业者 / 小微 team / 投 to C → 避开通用 Agent
  • 企业级 SaaS / 垂直 / 包装 → 可以做
  • 研究 / VC → 押注通用 Agent 仍有空间(模型升级也带不动垂直场景的整套 workflow)

2.3 分歧 3:多 Agent 编排该用什么"中心结构"?

视角 立场
老黄 newtype Profile Chief-Deputy-Specialist 层级(类 Hierarchical)
OpenAI Swarm / AutoGen P2P Swarm(对等) —— 多 Agent 互相对话
Google ADK / CrewAI Supervisor(中心化决策) + 8 大基础模式
王凯多浏览器矩阵 hub 协调层 ~/agents/_hub/ —— 不接浏览器,只读 logs + memory 做调度
Cal Rueb (Anthropic) 任务 tool sub-agent + 4 个并行 ~1.3x 速度 —— 谨慎使用

真分歧:架构选型取决于任务边界:

  • 任务边界清晰 + Agent 专业化分工 → Supervisor(LangGraph / CrewAI)
  • 协作型 + 多 Agent 写一篇论文 → P2P Swarm(AutoGen / OpenAI Swarm)
  • 大型复杂任务 + Architect/Coder/Reviewer 三层 → Hierarchical(CrewAI / MAF)
  • 实时系统 / 交易 / 监控 → Event-Driven(Kafka + Agent / Temporal + Agent)
  • 跨身份矩阵 / 防关联 → 王凯 hub + 身份隔离

2.4 分歧 4:Agent 是不是"内容/服务的新载体"?

老黄独家(newtype · Agent 架构与多 Agent 编排 §9 / 2026-01 帖 2274):

"旧内容只是信息的快照。新内容是一个封装了知识 / 逻辑 / 工具的实体。它是活的。用户对它的操作是'提问' / '调用' / '协作'。"

老黄立场:Agent 重新定义信息的"交付形态"和"消费方式" —— 它使内容不再仅仅是信息的载体,而是服务的载体。这对 Content Creator 是"掀桌子级的机会"。

其他作者无此判断:

  • 王凯偏工程实操(没把 Agent 当内容载体)
  • 研究报告偏技术架构(没扩展到内容创作)
  • AWS 偏行业落地

这是一条 only-老黄 视角,可以验证但不能强制。

3. 4 大编排模式 + Google ADK 8 模式速查(研究报告独家)

AI Agent 技术架构演进 2025(深度研究报告) §二:

3.1 4 大基础编排模式

模式 结构 适用 问题
Supervisor(监督者) 中心 Supervisor 路由任务到各 Agent 任务边界清晰 / 专业化分工(客服 → billing/技术/退款) Supervisor 成瓶颈;高并发时延迟累积
P2P Swarm(对等蜂群) Agent 之间直接对话,无中心 协作型任务(多 Agent 写论文) 难以预测和调试;容易出现死循环
Hierarchical(层级) CEO → VP → Worker × N 大型复杂任务(Architect / Coder / Reviewer 三层) 层级深 = 延迟累积;每层可能丢信息
Event-Driven(事件驱动) Agent 订阅事件,触发后异步处理 实时系统(交易、监控、告警) 状态管理复杂;事件顺序不可控

3.2 Google ADK 8 大基础模式

  1. Sequential(顺序流水线)
  2. Parallel(并行汇总)
  3. Loop(循环迭代直到达标)
  4. Router(基于内容路由)
  5. Fork-Join(分发-汇总)
  6. Map-Reduce(大数据分块处理)
  7. Reflexion(自反思自纠正)
  8. Hierarchical Plan-Execute(规划-执行分离)

3.3 6 大主流框架对比

框架 出身 编排模式偏好 上手难度
LangGraph LangChain 团队 Supervisor + 自定义图 中
CrewAI 独立 Supervisor + Hierarchical 低
MAF(Microsoft Agent Framework) Microsoft Hierarchical 中
AutoGen Microsoft P2P Swarm 高
LlamaIndex LlamaIndex 团队 Workflow-driven 中
Google ADK Google 8 大基础模式 高

详细选型决策树见 AI Agent 技术架构演进 2025(深度研究报告) §六。

4. MemoryOS:Agent 记忆系统 3 层架构(研究报告独家)

AI Agent 技术架构演进 2025(深度研究报告) §三 / 论文 arXiv:2506.06326:

层级 全称 类比人脑 存储介质 生命周期
STM Short-Term Memory(短期记忆) 工作记忆 内存 / context window 当前 session
MTM Mid-Term Memory(中期记忆) 海马体 Redis / 关系数据库 数天-数周
LPM Long-term Personal Memory 大脑皮层 向量数据库 + KV 永久

关键设计原则:

  • 不是所有信息都进 LPM —— 用 LLM 自动判断重要性
  • 遗忘是特性 —— STM 自动 decay,MTM 周期清理,LPM 只保留用户验证过的
  • 可解释性 —— Agent 能告诉用户"我记得 X 是因为你上次说 Y"

向量库选型决策树:

  • 千万级 + 已有 PG → pgvector
  • 千万级 + 新建 → Pinecone / Qdrant
  • 亿级 → Milvus(分布式)
  • 多模态 → Weaviate
  • 原型 → Chroma

Mem0 框架(arXiv:2504.19413)是 MemoryOS 思路的开源实现 —— 跟 LangGraph / CrewAI / OpenAI / Anthropic 即插即用。

5. 王凯多浏览器矩阵(独家)

王凯多 Agent 浏览器矩阵架构(v1.1 实操指南) —— 一台电脑 × N 套独立身份 × M agent 的工程化实现:

5.1 核心定义

身份 (Identity)  = 一个浏览器 app + 一套登录态 + 一个住宅 IP + 一个 cdp-proxy 进程
   ↓
工种 (Role)      = 一个 Claude Code agent(独立工作目录),跟同身份其他 agent 共享同一个浏览器实例

"agent" = 一个独立的 Claude Code 终端窗口/会话,不是 Claude Code 内部的 sub-agent / Task 工具。

5.2 端口对分配(按身份维度)

身份 浏览器 app proxy 端口 chrome 调试端口 住宅代理出口
identity-A Chrome 9401 9222 US-East
identity-B Arc 9402 9223 US-West
identity-C Brave 9403 9224 UK
identity-D Edge 9404 9225 DE
identity-E Vivaldi 9405 9226 JP

5.3 4 重隔离

  • 浏览器隔离(不同 app)
  • 账号隔离(独立 Google / 独立用户数据目录)
  • IP 隔离(住宅代理出口)
  • 指纹隔离(Multilogin / GoLogin / AdsPower)

5.4 同身份内的多 agent

所有 agent 的 .mcp.json 都指向同一个 proxy 端口(如 identity-A 下的所有 agent 都指 9401)。chrome-mcp-proxy 通过 sessionId 路由保证它们看到的事件互不干扰。

5.5 hub 协调层

~/agents/_hub/ —— 不接浏览器,只读 logs + memory 做调度。是王凯独家的"调度但不执行"中心。

6. Agent 分级 L1-L5(王凯独家)

王凯 Agent 工程实操 §2(参考自动驾驶):

等级 描述 当前位置
L1: 单点辅助 人提任务,AI 写,人执行 普及
L2: 多步辅助 AI 帮人拆解任务、引导 Cursor / v0 / 深度研究
L3: 半自主 人监督下 AI 完成多步任务 Devin / Claude Code Agent
L4: 完全自主 无需人介入,Agent 完成复杂任务 待 token 价再降 90%
L5: Agent 组织 多 Agent 协作完成组织级任务 OpenAI L5 设想

王凯当前定位:L3 半自主(Claude Code 跑投资策略 / 自动推广)。

Cat Wu / Embiricos 视角对照(Lenny's Newsletter / 2026 AI 时代组织运营三人谈(Anthropic + OpenAI)):

  • "AGI 限制因素 = 人类打字速度 / 多任务管理速度"
  • "明年(2026)— 早期 adopter 看到 agent self-sufficient(智能体自给自足)"
  • "几年后 — 大公司跟进"

7. AWS Agent 4 篇精华(独家行业实战)

AWS Agent 系列讲座 2025(4 篇汇编) 4 篇精华:

7.1 汪其香:Reasoning Model + Multi-Agent Orchestrator + 6 大框架对比

  • 6 大框架综合实战对比

7.2 王晓妍:Agentic AI 4 要素 + 段位 3 级 + RL + 产品定价 + 3 条曲线

7.3 常高伟:ANP 协议(智能体 email,对标 MCP USB-C)

  • W3C DID + P2P
  • ANP vs MCP:MCP 是"USB-C"(连接工具),ANP 是"email"(Agent 间直接通信)

7.4 idoubi:独立开发 10+ AI 产品 + 一小时上线 SOP

  • ProductHunt 上线策略
  • 程序化 SEO
  • 5 个 all-in 方向

8. Agent 论文 3 篇精华(独家学术视角)

Agent 研究论文 3 篇精读(2024-2025):

8.1 CAMEL-AI《Finding the Scaling Laws of Agents》(Wendong Fan)

  • # Agents 取代 # Parameters —— Scaling Law 的"新 X 轴"
  • OWL / CRAB / OASIS / DataGen 4 项研究

8.2 Tencent《More Agents Is All You Need》

  • sampling-and-voting 暴力堆 Agent 数量
  • Llama2-13B + 15 agents = Llama2-70B
  • 3 维度 gain / step-wise + hierarchical

8.3 NVIDIA《ChatQA》

  • 70B QA model + two-stage tuning
  • fine-tune retriever 替代 GPT-3.5 rewriting
  • 1.5K unanswerable 样本降幻觉

9. Codex / Cloud Code 视角(Anthropic + OpenAI 内部)

Lenny's Newsletter / 2026 AI 时代组织运营三人谈(Anthropic + OpenAI):

9.1 Embiricos (OpenAI Codex 负责人) 关键洞察

  • GPT-5 后 20× 增长 / 每周服务数万亿 tokens / API 第一名
  • Compaction 是关键创新 —— 让模型连续工作超过 context window(模型 + API + harness 三层协调)
  • 愿景:Software engineering teammate(像"非常聪明的实习生但拒绝看 Slack 监控")
  • 设计哲学:Mixed-Initiative(混合主动,human empowerment + assistance,不是 autonomy max)

9.2 Cat Wu (Anthropic Cloud Code PM Head)

  • Cloud Code 多形态(终端 / 桌面 / web / mobile / Cowork)
  • Cowork = Claude with Hands —— 非代码任务(Slack 0 / Inbox 0 / 写 deck)
  • 移除 crutch(拐杖功能)—— 早期 to-do list 帮模型做大重构,新模型不需要了就移除

9.3 AI 时代三层框架(老黄 newtype · Agent 架构与多 Agent 编排 §11 一致)

层 内容
技术栈 底层模型 → 中层基础设施 → 上层应用场景
价值链 供给侧 → 传导层 → 需求侧
竞争格局 通用层(模型厂商)→ 基础设施层(独立玩家)→ 应用层(垂直公司)

对创业者的战略意义:

  • 底层(模型/引擎/记忆系统)→ 追求通用性,目标成为基础设施
  • 中层(Harness/工具集)→ 追求最佳实践,目标成为事实标准
  • 上层(垂直应用)→ 追求场景化,目标建立领域护城河

9. 深思圈 Agent 公司视角(659 篇独家)

入口:深思圈作者全集入口

主题 wiki(2026-05-18 补建):

9.1 Cursor "训练即产品"(2025-11)

Sasha Rush at Ray Summit 2025:Composer 模型 token 效率 4 倍 + 同 microVM 环境训练 + 生产。

"通过生产 Cursor 产品进行训练 —— 生产 agent 服务器,在运行云 agent 和训练强化学习时是完全相同的。"

3 大技术挑战:训练与推理匹配 / 超长 rollout / 训练-生产一致性。

9.2 Anthropic 护城河:权限 > 智力(2026-05)

深思圈 / AI Agent 公司案例库 §2:

"企业 AI 里最稀缺的东西,正在从「智力」转向「权限」。"(Jaya Gupta)

含义:Agent 上生产难度不在模型,在法务 / 风控 / 董事会签字同意让 AI 自主执行。

9.3 Agent 4 类型 + 11x 暴雷教训

类型 代表
水平 Agent Imbue(10 亿估值)/ Manus / Devin
编程 Agent Cursor / Lovable / Devin / Replit
垂直 Agent Harvey / 11x / Decagon / Eve
Agent 基建 LangChain / Agent Git(a16z 1700 万)/ Agent 保险(1500 万)

11x 暴雷教训:AI SDR / 数字员工不能只是自动化任务,必须解决组织信任 / 权限(Jaya Gupta 视角)。

9.4 反框架共识(Cursor / Perplexity / Lovable)

"揭秘 Cursor、Perplexity、Lovable 的技术内幕:为什么它们都选择'反框架'路线"

不用 LangChain / AutoGen / CrewAI → 自己写底层 → 更可控更快。

10. 怎么选 —— 按身份的 Agent 架构路径

你是谁 主用架构 起点
独立开发者 / 矩阵化运营 王凯多浏览器矩阵 身份 × 工种 + cdp-proxy 隔离 + hub 协调
Anthropic 风格的 PM / 工程师 Cal Rueb 的 Task sub-agent + Cowork(非代码任务) 谨慎用 Sub-Agent(4 并行 ~1.3x)+ Cowork 处理 Slack/Deck
企业级 Agent 项目 4 大编排模式 + 6 框架选型 Supervisor / Hierarchical / Event-Driven 按任务边界选
Content Creator 老黄 Agent = New Content 把内容封装成 Skill / 插件 → 用户调用
想做研究 / 学术派 CAMEL + More Agents sampling-and-voting + Scaling Laws of Agents
VC / 投资人 深思圈 / a16z 视角 看垂直深度 + 记忆资产 + 是否被模型升级吃掉

通用起步顺序(任何身份):

  1. 画 Workflow —— Agent 之前先画流程图,把每一步用人话写清楚(老黄 §1)
  2. 过 3 法则 —— 任务明确 / 场景封闭 / 结果可验证(老黄 §5)
  3. 从 Workflow 起步 —— 只在确实需要"理解 + 决策"的节点插入 Agent
  4. 选编排模式 —— 任务边界清晰 → Supervisor;协作型 → P2P;复杂大型 → Hierarchical;实时 → Event-Driven
  5. 加 MCP 工具 —— 数据准确性场景必须走 MCP(王凯 FMP 案例)
  6. 加 Memory —— 跨 session 任务用 MemoryOS / Mem0(STM/MTM/LPM 3 层)
  7. 可观测:10min 巡检(王凯)+ Stop hook 响一声(Cal)

11. 引用清单

主要原始 author wiki:

相关主题 wiki(本系列):

2026-05-19 增补:Anthropic 工程团队第一方视角

2026-05 抓 anthropic.com/engineering 25 篇,加 Anthropic 自己对"agent 怎么搭"的判断作为本 wiki 的"第 7 视角"(原 6 视角 = 老黄帖子级 / 研究报告 / 王凯矩阵 / AWS / 学术论文 / Anthropic-OpenAI 内部访谈)。

Building Effective Agents 5 patterns(canonical)

Anthropic 把 LLM 系统分:Workflow(预定义路径)vs Agent(动态自主)+ 5 个 building block。官方反复强调"successful implementations weren't using complex frameworks" —— 跟老黄、王凯、idoubi 共识一致。

Workflow side:
  1. Prompt chaining
  2. Routing
  3. Parallelization (sectioning / voting)
  4. Orchestrator-workers
  5. Evaluator-optimizer

Agent: 模型自己决定下一步,工具调用循环

Anthropic 官方判断:"agentic systems often trade latency and cost for better task performance" —— agent ≠ "更高级",是"更贵更慢更灵活"的取舍。

跟老黄"Agentic Workflow"(骨架 Workflow + 关键节点 Agent)+ 王凯"L1-L5 分级"互校一致。

4 类 Harness 场景(2025-2026 演化)

Anthropic 把 agent harness 按场景分 4 类(来自 6 篇相关文章):

场景 Harness 名 代表 Anthropic 文
单次会话 标准 agent harness Claude Code 默认 / Cursor claude-code-best-practices
长跑 single agent initializer + coding agent(两件套) Agent SDK 长跑模板 effective-harnesses-for-long-running-agents
主观品质长跑 GAN 启发(agent A 写 + agent B 评) Frontend design / app build harness-design-long-running-apps
多 agent 并行 planner + workers + synthesizer Claude.ai Research multi-agent-research-system
Decoupled managed "Brain 跟 hands 分离" platform Managed Agents managed-agents(2026 新)

关键经验:"harness 假设会 go stale"(过期)—— Sonnet 4.5 的"context anxiety"(快没 context 时仓促收尾)在 4.6 没了,旧 harness 变累赘。Managed Agents 思路:让 harness 跟着模型升级自动调整,不是每次升级都重写。

Carlini 16 Claude 写 C 编译器(实证多 agent 上限)

来自 building-c-compiler(Nicholas Carlini, Safeguards 团队):

  • 16 个并行 Claude 实例,从零写 Rust-based C 编译器
  • 近 2,000 次 Claude Code 会话 + $20,000 API 费
  • 产出 100,000 行编译器,能编译 Linux 6.9 跑 x86/ARM/RISC-V
  • 代码开源 anthropics/claudes-c-compiler

学到的设计原则:

  1. 写测试让 agent 不跑偏(无人监督下,测试是唯一对错信号)
  2. 任务结构化让多 agent 并行不撞车
  3. agent 团队规模化有 upper bound —— 不是无限堆 agent 就能搞定任意大项目

意义:这跟 Agent 研究论文 3 篇精读(2024-2025) More Agents Is All You Need 学术派的"# agents 取代 # parameters"形成对照 —— Anthropic 第一方实证:数量有 ceiling,Workflow 设计才是命门(老黄印证 §1.2)。

Multi-Agent Research System 架构细节

Anthropic Research 功能(Claude.ai 内)的实际架构:

[规划 agent]   接用户问题,拆 N 个并行子查询
     ↓
[N 并行子 agent]  各自跑 web 搜索 / Google Workspace / integrations
     ↓
[合并 agent]   综合所有结果,写报告

反复强调的痛点:

  • 协调成本(子 agent 之间传 context 烧 token 飞)
  • 评测难度(评的是"整个团队"不是单 agent)
  • 可靠性问题(1 个 agent 5% 挂率,N 个团队挂率 = 1−(0.95)^N)

跟 AI Agent 技术架构演进 2025(深度研究报告) 4 编排模式互校 —— Anthropic 走的是 Hierarchical Plan-Execute 模式,典型企业级部署模式。

Eval 是 Agent 工程化必修(参考)

详细见 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive)(Phase A 锚)+ LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战)(跨作者综合)。关键点:

  • agent eval 评的是 agent harness + 模型 这对组合,不是单评模型
  • Capability suite(起 20-40%)+ Regression suite(近 100%)双轨
  • pass@k vs pass^k 数学:k=10 时 75%→100% 还是 75%→5.6% 走向相反
  • 基础设施噪声 > 模型差异:Terminal-Bench 上换 infra 配置就能差 6 个点
  • Eval awareness:Opus 4.6 在 BrowseComp 上自己识破被测 + 解密 answer key(史上首次记录)

History

2026-09 增补：无人值守流水线如何留下可验证结果

本节基于 2026-06-15 保存的 VoidSpark 源码拆解笔记，是设计案例的整理；本次未重新运行项目。笔记描述的阈值属于该项目配置，不是所有流水线的通用最优值。

1. 把流程状态和执行者分开

每个任务保留明确状态，各执行环节根据状态领取工作。通用流程只读取项目配置，避免把某个业务名称、路径或预算写死在流程里。这样替换一个执行者时，其他环节仍能从持久状态判断下一步。

流程可以分为选题、定义、实现、运行、裁决等关卡；每个关卡分别安排产出与审核，并给返工设上限。案例使用最多三轮返工：它的作用是防止无限循环，并不意味着三轮一定足够验证任何任务。

2. “没改善”与“实验无效”必须分开

结果 含义 后续动作
WIN 有改善 保留结果及比较依据
NULL 没有观察到改善 记录已验证的无效方向，避免重复试验
FAIL 结果变差 保留失败证据，回退到仍可用的结果
DRIFT 本轮条件失效，结果不可比较 修复实验条件，再判断是否值得重跑

如果把 NULL 和 DRIFT 都叫失败，下一轮就无法区分“方向试过没用”与“其实还没有有效测试”。同理，抓取失败时应保留上一次成功产物，不能拿空文件覆盖。

3. 长跑流程需要四类约束

  • 重复触发约束：心跳或定时触发必须幂等，即多触发一次不会额外启动同一份任务。
  • 并发约束：在途任务与候选队列都设上限，防止短时输入增长压垮接口。原笔记中的并发上限 2、在途任务低于 5 时补货且不超过 20 的水位控制只是案例参数。
  • 认领与回收约束：记录谁正在执行、最后活动时间与超时条件。回收前要判断执行者是否仍在工作，避免把慢任务重复启动。
  • 产物替换约束：先写临时结果，成功且通过非空检查后再替换正式结果；只追加的状态日志用于回放失败位置与各阶段耗时。

4. 无人值守不等于无限授权

提示词应明确已授权的任务可以继续执行，并定义无法继续时的退出状态。案例提出的“直接做，别问”只适用于边界明确的后台工作，不能取代发布、付款或权限变更的授权。危险开关默认关闭，可回滚的小动作再按项目政策决定默认值。

对于模型限流，设计上应有可观测的失败信号与备用路径；切换前保留进度并避免重复副作用，不能把“看到限流就杀掉重跑”当成无条件规则。

5. 让复盘反过来减少重复劳动

保留已完成与已否决清单，生成阶段先判断候选是否值得投入，再进入昂贵的执行和审核。每个产物附一句非技术读者能理解的说明，便于人快速判断它解决了什么问题。

监控优先盯一个能暴露流程堵点的关键现象。VoidSpark 的案例关注 GPU 空转；内容更新流程可关注“有新资料但没有有效产出”。这是定位瓶颈的入口，不能用单一指标代替成本、安全和质量约束。

来源与关联资料

2026-10-17 追补：把复杂判断拆成可测部件，再选择错误阈值

来自10月16日 Builders 对 Diogo Almeida / Jev 访谈的整理。属于嘉宾的方法与供应商观点，未复现产品基准；不重复本页已有的类型安全、概率校准与业务授权说明。

先让每个判断能单独失败

邮件助理可以分别判断是否为销售联系、招聘联系，以及是否点名要求本人处理，再由代码组合结果。相比把所有偏好塞入一个大提示词，拆分后更容易定位哪一项判断错了，并把失败样本加入对应测试集。拆分是否有用，应看错误能否定位、测试能否复用，而不只看模块数量。

组合后仍需检查完整流程。每个分类器单独表现可接受，不保证组合规则没有遗漏或冲突；一封邮件也可能同时满足多个条件。可为交叉情况保留样本，检查规则的优先顺序以及无法判断时的路径。这是本库的应用建议，并非访谈声称已解决邮件排程。

阈值反映业务更怕哪一种错

错过重要来信与多看一封普通来信的代价不同，因此不宜给所有判断共用一个阈值。先分别记录漏掉目标、误报目标会造成什么后果，再用真实样本观察改变阈值后这两类错误如何变化。阈值表达的是取舍，不是让模型突然变得更确定；不能把调低告警量当成准确率提升。

训练目标和数据也决定行为

Almeida 讨论的 RLCD 不只是更换强化学习算法，也包含输入输出形式、训练数据、平衡方式与优化目标。他介绍团队自制数据并组合开放权重模型，没有从头预训练。可迁移的检查是：数据是否包含业务关心的边界例子，优化目标是否体现主要错误代价，结果是否在实际流程里验证。此处未取得完整训练配方，不推导出可直接复现的算法或性能排名。

何时用：一个提示词同时承担许多判断、上线后难以定位错误时。先拆一组能明确标注的判断，再评估维护成本。规则已经清晰且任务量很低时，确定性代码可能更合适。

Addition: Test decision components separately and choose thresholds by error cost

This addition is based on the October 16 Builders account of the interview with Diogo Almeida about Jev. It records the guest’s methods and supplier claims without reproducing product benchmarks. The existing discussion of type safety, probability calibration and authorization remains unchanged.

An email assistant can separately assess whether a message concerns sales, recruiting or a request for the recipient’s personal attention, then combine those judgments in code. Separate tests make failures easier to locate and retain as regression examples. More modules alone are not evidence of better design. The combined workflow still needs tests for overlapping conditions, precedence and uncertain cases. These are proposed applications, not a claim that the interview solved email scheduling.

Missing an important message and reviewing an extra ordinary message have different costs. Specify those costs before choosing thresholds, then observe both missed targets and false alarms on actual samples. A threshold expresses a trade-off; reducing alerts does not by itself demonstrate improved accuracy.

Almeida describes RLCD as involving input and output design, training data, balancing and objectives, rather than merely a different reinforcement-learning algorithm. He says the team builds its own data and combines open-weight models instead of pretraining from scratch. Check whether data covers relevant boundary cases, whether objectives reflect costly errors and whether results hold in the actual workflow. The account does not provide a complete reproducible training recipe or independent performance ranking.

Use this approach when one prompt handles many decisions and failures are difficult to isolate. Start with judgments that can be clearly labeled and compare maintenance costs. For low-volume tasks with clear rules, deterministic code may be sufficient.

Read in English ↓

2026-10-18 增补：把环境、反馈、协作与行动责任连成可交付的Agent

42章经多期访谈为上文编排与验证补充了产品视角：从2023年的Dify到2025年的Pokee、Grasp，再到2026年的黄东旭实操、Junior、Slock。它们是不同时间与不同任务的实践，不是已经确定的统一技术路线；历史能力与价格不作为当前基准。

决定下一步之前，先让任务拥有可观察的状态

先写清目标、当前状态、可用动作、结果反馈和失败回退。缺某个API、供应商只接电话、登录会话已失效，都可能使本来正确的规划无法完成。模型能表达一份计划，不等于环境能执行它，更不等于结果已交付。

Pokee把RL（从行动反馈学习策略）的决策核和LLM（理解语言与生成表达）分工。其适用判断比“Agent必须用RL”更有用：是否需要在多个未知动作中探索、前一步是否影响后续资源、是否能观察并改进长期结果。吴翼的强化学习访谈强调理解环境与连续决策互补，并举信息不全时先问环境版本的例子。应用团队尚无可靠环境、验收和样本时，先补这些环节，未必从训练模型开始。

几类路线保留不同边界：规则适合稳定流程，模型规划适合需要判断的步骤，训练适合有足够反馈的反复任务。一次任务也可以混合使用。发现十一步走不通时，系统需知道能回到哪一步、哪些外部状态已改变；不能靠重新输出一遍方案把副作用抹掉。

环境不是一张工具清单，还包括恢复与可控制的影响范围

Grasp区分运行环境、决策循环、行业知识与验收：页面能加载与任务能完成不是同一件事。其状态保存案例关注中断后一小时还能继续、闲置时少耗资源；黄东旭则把技能、环境状态和上下文一起封装。两者相接后，复用单位应至少包含：输入、工具及版本、登录/权限、数据位置、过程游标、完成证据和失败恢复。

云端与本地在访谈中存在分歧。雷磊更看重云端弹性和持续运行；黄东旭认为本地与云端都可运行，但要考虑控制和维护。不能把其中任何一个预测变成唯一部署答案。实际选择看数据要求、可观察性、成本、任务时长、停机恢复与谁能中止执行。

沙盒（限制代码能影响哪些文件、网络与系统的环境）的价值是限制最坏后果，而不是让所有行为天然安全。登录模块能使用凭据与把密码放进模型上下文也不同；会话恢复需要确认身份和权限仍有效，不能只看进程还活着。

组织记忆与个人记忆，服务对象和传播边界不同

Junior强调企业员工不是主人的分身。它要认识公司、项目、角色和职责，但小团队一个Agent知道全公司，不应直接扩展到万人组织。记得老板私聊不等于允许在群里转述，知道客户信息也不等于任何销售都能读取。

因此记忆可用性至少分两问：这条信息是否有助当前任务；当前接收者是否有权得到它。人物身份、项目、时点、信息来源和可分享范围应随内容一起保存。角色标签仅便于引导，不是硬权限；工具与数据访问需要系统状态和可审计约束。

高途案例提供另一种记忆用途：线索的历史、意向、试听与疑问形成报告，再交给真人完成签约。它说明完整上下文首先服务于交接质量，并不要求Agent知道客户所有生活资料。

多Agent先减少重复认领和失去上下文，再追求更多并行

Slock指出人可以看见旧线程在哪，模型接收到的却是一串混合事件。仅给消息ID或@名字，不一定足以知道正在谈哪件事、自己是什么身份。进入一条工作线程时提供主题、相关旧消息摘要、当前负责者和下一动作，比把全部群聊塞进同一上下文更有针对性。

任务认领应有排他状态：谁接了、何时开始、产物在哪、由谁验收。只提示“不要重复做”，缺少共同任务状态，仍可能多人同时改一份文件。黄东旭提到同模块高速改动互相覆盖；并行可先用于模块边界清楚、结果能独立验证的工作。主Agent也需要根据真实产物对账，不能把每个子Agent自报完成直接合计。

群体提醒可促进纠错，也可能共享同一错误。Slock看到一个Agent被纠偏后提醒另一个，是协作观察，不证明多Agent共识一定可靠。比较架构时应计入上下文复制、等待、冲突、审核和token成本，以每份合格交付的总成本与时间判断收益。

评测同时覆盖完成、回归、澄清和拒绝越界

丁丁谈评估把真实输入、完整输出与业务标准作为最小测试单元。公开榜单看基础能力，自有任务集看业务，不应互相替代。可用下列维度设计端到端用例：

维度 应观察什么 失败例子
理解与澄清 识别缺信息并及时问关键问题 不问环境版本就反复改错
动作与状态 正确工具、参数和状态回读 页面显示成功但订单/文件未产生
结果与交接 产物符合需求，下一个人可复查继续用 只有漂亮总结，没有依据和输出
回归与覆盖 新旧任务、不同人群和长尾均有样本 新能力升分，旧核心流程退化
权限与保密 不传播无权信息，不做未授权动作 回答群问题时引用老板私聊
恢复与更正 错误后停止、解释影响、留下修正记录 重跑重复发送，或静默用零替缺失

Junior同时保留固定回归集和一线成员探索新模型的路线：旧题不退化与发现新用途是两件事。需要留出的未知样本减少刷题，并保留版本可比性；自动裁判与人工、在线行为交叉校准，不能把模型的“通过”当客观事实。

Character.ai后训练进一步给出产品指标反例：平均对话时长上升可能来自模型回避敏感话题时不断反问，而重度用户体验下降。编辑、删除和重生成能帮助构造偏好样本，但要保留上下文和原因；不能把所有编辑都当更喜欢某种文风。数据用于训练前还需满足其原有使用范围。长期关系的好坏、单轮讨好和短期参与应分别检验。

判断、验证与行动之间，保留明确责任

Vibe-Trading访谈把模型产出假设、Harness（约束执行与验证的系统）把关、人负责范围与例外分开。它最适合迁移的是数据口径、公开时点、版本和缺失的检查；不是以解释充分保证交易盈利，也不是让“赚钱”成为唯一代码正确性标准。

可将业务写入做成建议→预览→执行→回读，动作绑定依据、作用范围与可接受损失。信息不足就明确停在不能判断，数据源失败标缺失，不静默填零。自纠错报告说明发现过一次错误，不代表以后可免核验；多步判断共用同一错误来源时会相关失败，不能直接把每步自信相乘。

成本与运营是架构验收的一部分

Junior按任务固定收费遇到同名任务需要十至三十轮的问题，后来改变计费和用户入口；低价学生素材带来高曝光却无法覆盖服务成本。这提示应计完整多轮成本，而非单次API价格。Dify则强调运营者要持续更新资料、工具和提示，模型替换后也需要重跑业务测试。

本节的应用顺序是：先用一个真实任务验证信息—动作—回读，明确权限、恢复和成本；再扩充任务集、并行规模和自主程度。以上来自访谈机制的编辑提炼，不代表已独立验收上述产品，也不要求所有任务采用同一模型、RL或多Agent架构。

工具复用与过程可见，还要补上数据完整性

Sheet0王文锋强调Context（当前任务可用信息）包括代码结构、网页、表格和工具执行结果；每次反馈改变下一步。测试过的查询与执行部件应复用，开放判断留给需要它的环节。但“脚本运行”“表格没有空格”“保留一次成功代码”都不足以保证所有输入下100%正确。对采集任务还要核对起止边界、页数、唯一ID、总数、缺失原因与字段来源；对发布任务核对实际存储与公开结果。用户看见浏览器在操作有助掌控，却不能替代这些完成证据。

Gru张海龙讨论单元测试Agent的窄切口和多仓库题库，说明重复劳动可以形成清楚的输入输出；但生成测试也可能把现有bug当预期行为固定下来。因此需要独立定义应有结果，覆盖率和通过率只能在测试本身正确的前提下解释。

同一产品的跨期修正：别把准确率口号当验收标准

2025年Sheet0访谈强调稳定、完整地抓取和处理结构化数据；2026年3月王文锋再访时，在51:51明确承认此前追求百分之百准确，模型实际上做不到，而且当期用户的主要瓶颈也不是这一点。这段变化应与早期主张一起阅读：结果准确性仍须验收，但产品优先级要由真实任务的阻塞点决定，不能把上一阶段的营销表述固化成技术保证。可执行的做法是分别记录漏行、错列、缺字段、无法获取和需人工确认项，给出可复核的完成范围，再根据用户损失排序修复。2026年再访

工程资产的稳定层与可替换层

2025年12月Dify再访把2023年的Prompt/RAG工具，追溯到企业Workflow、插件与多模型协同：模型升级不应迫使用户重建全部流程，插件、检索组件和模型接口可替换，敏感业务字段、已审批节点及既有资产则需要兼容承诺。嘉宾所谓“可投产”不是单一准确率，也不等于零故障；具体应验收旧流程回归、字段结构、异常停靠、人机复核、升级与回滚。四五百节点或上千流程是客户案例自述，不能从规模推出全自动管理已经成立。对组织之间的非标协作，Workflow的意义在于清楚表达谁执行、谁反馈、哪里必须放人；当人反复抽卡挑出一份结果时，交付责任仍在人。此处与2023年早期Dify笔记构成阶段演变，不能把后来能力倒填成初版已有。Dify2025再访

English version

Added 2026-10-18: Connecting Environment, Feedback, Collaboration, and Responsibility into a Deliverable Agent

Several 42 Zhangjing interviews add a product perspective to the orchestration and verification discussed above: from Dify in 2023 to Pokee and Grasp in 2025, then Huang Dongxu’s practical work, Junior, and Slock in 2026. These are practices from different periods and tasks, not an established, unified technical path. Historical capabilities and prices are not current benchmarks.

Before Deciding the Next Step, Give the Task Observable State

First define the goal, current state, available actions, outcome feedback, and fallback after failure. A missing API, a supplier who only takes phone calls, or an expired login session can prevent an otherwise sound plan from being completed. A model’s ability to express a plan does not mean the environment can execute it, much less that the result has been delivered.

Pokee separates the decision core built on reinforcement learning (RL, learning policies from action feedback) from the large language model (LLM, understanding language and generating expression). Its criteria for applicability are more useful than the claim that “agents must use RL”: does the task require exploring several unknown actions, do earlier steps affect later resources, and can long-term outcomes be observed and improved? Wu Yi’s interview on reinforcement learning emphasizes the complementary roles of understanding the environment and making sequential decisions, including the example of first asking for the environment version when information is incomplete. Application teams without reliable environments, acceptance criteria, and samples should fill those gaps first; they need not begin by training a model.

Different approaches retain different boundaries. Rules suit stable processes, model planning suits steps requiring judgment, and training suits repeated tasks with sufficient feedback. A single task can combine them. When an eleven-step path fails, the system needs to know which step it can return to and which external states have already changed. Generating the plan again does not erase side effects.

An Environment Includes Recovery and a Controllable Scope of Impact, Not Just a Tool List

Grasp distinguishes the runtime environment, decision loop, domain knowledge, and acceptance: a page loading and a task being completed are different things. Its state-preservation example focuses on resuming after an hour-long interruption and consuming fewer resources while idle. Huang Dongxu packages skills, environment state, and context together. Combining these ideas suggests that a reusable unit should include at least its inputs, tools and versions, login and permissions, data locations, progress cursor, evidence of completion, and failure recovery.

The interviews disagree about cloud and local deployment. Lei Lei places greater weight on cloud elasticity and continuous operation; Huang considers both local and cloud execution viable, with control and maintenance as considerations. Neither prediction should become the only deployment answer. The practical choice depends on data requirements, observability, cost, task duration, recovery after downtime, and who can stop execution.

A sandbox—an environment limiting which files, networks, and systems code can affect—limits the worst consequences; it does not make every action inherently safe. A login module being able to use credentials is also different from putting a password into model context. Restoring a session requires confirming that identity and permissions remain valid, not merely that the process is still alive.

Organizational and Personal Memory Serve Different Audiences and Have Different Sharing Boundaries

Junior emphasizes that an enterprise employee is not the owner’s alter ego. It needs to understand the company, projects, roles, and responsibilities, but an agent knowing everything about a small team should not be directly extended to an organization of ten thousand people. Remembering the boss’s private conversation does not authorize repeating it in a group, and knowing customer information does not mean every salesperson may access it.

Memory usability therefore involves at least two questions: does this information help the current task, and is the current recipient entitled to receive it? Identity, project, time, information source, and permitted sharing scope should be stored alongside the content. Role labels help guide behavior; they are not enforceable permissions. Access to tools and data requires system state and auditable constraints.

Gaotu’s case offers another use of memory: a lead’s history, intent, trial lessons, and questions form a report that is handed to a human to close the sale. It shows that complete context first serves handoff quality, without requiring the agent to know every detail of the customer’s life.

Reduce Duplicate Claims and Lost Context Before Pursuing More Multi-Agent Parallelism

Slock notes that people can see where an old thread belongs, while a model receives a mixed stream of events. A message ID or an @mention alone may not tell it which matter is under discussion or which identity it is acting under. When entering a work thread, supplying its topic, a summary of relevant earlier messages, the current owner, and the next action is more targeted than putting the entire group conversation into one context.

Task claims need an exclusive state: who accepted the task, when work began, where the artifact is, and who will accept it. Merely saying “do not duplicate work,” without shared task state, can still leave several agents editing the same file. Huang describes rapid changes to the same module overwriting one another. Parallelism can begin with work whose module boundaries are clear and whose results can be independently verified. The lead agent also needs to reconcile actual artifacts rather than simply adding together every sub-agent’s self-reported completion.

Reminders among agents may improve correction, but can also spread the same mistake. Slock’s observation of one corrected agent reminding another is an observation about collaboration, not proof that multi-agent consensus is necessarily reliable. Architecture comparisons should include context duplication, waiting, conflicts, review, and token costs, judging the benefit by total time and cost per acceptable delivery.

Evaluate Completion, Regression, Clarification, and Refusal to Exceed Boundaries

Ding Ding’s discussion of evaluation takes real input, complete output, and business criteria as the minimum test unit. Public leaderboards assess general capabilities; an internal task set assesses the business. Neither should replace the other. End-to-end cases can use the following dimensions:

Dimension What to observe Example failure
Understanding and clarification Identify missing information and ask critical questions promptly Repeatedly making incorrect changes without asking for the environment version
Actions and state Correct tools, parameters, and verification by reading back state The page reports success, but no order or file was created
Results and handoff The artifact meets requirements and can be checked and continued by the next person A polished summary without supporting evidence or output
Regression and coverage Samples cover old and new tasks, different user groups, and the long tail A new capability scores higher while an existing core process deteriorates
Permissions and confidentiality Do not share unauthorized information or take unauthorized actions Citing the boss’s private conversation while answering a group question
Recovery and correction Stop after an error, explain its impact, and retain a correction record Retrying causes a duplicate send, or missing data is silently replaced with zero

Junior retains both a fixed regression set and a path for frontline staff to explore new models. Preventing degradation on old questions and discovering new uses are different activities. Held-out, unseen samples help reduce teaching to the test, while version comparability must also be maintained. Automated judges should be cross-calibrated with humans and online behavior; a model’s “pass” is not an objective fact.

Character.AI’s post-training discussion provides a further counterexample in product metrics. Average conversation duration may increase because the model keeps asking questions to avoid sensitive topics, while heavy users’ experience declines. Edits, deletions, and regenerations can help construct preference samples, but their context and reasons must be retained. Not every edit means a preference for a particular writing style. Training use must also remain within the data’s original permitted scope. The quality of a long-term relationship, pleasing someone in a single turn, and short-term engagement should be tested separately.

Keep Responsibilities Explicit Between Judgment, Verification, and Action

The Vibe-Trading interview separates the model producing hypotheses, the harness—a system constraining execution and verification—providing checks, and the human owning scope and exceptions. Its most transferable elements are checks on data definitions, public availability dates, versions, and missing data. A thorough explanation does not guarantee trading profit, and “making money” is not the sole criterion of code correctness.

Actions that change business data can follow proposal → preview → execute → readback, with each action tied to its evidence, scope, and acceptable loss. Insufficient information should explicitly stop the process at “cannot determine.” A failed data source should be marked as missing, not silently filled with zero. A self-correction report shows that one error was found; it does not exempt future work from verification. Multiple judgments sharing the same incorrect source can fail together, so their individual confidence levels cannot simply be multiplied.

Cost and Operations Are Part of Architectural Acceptance

Junior encountered tasks with the same name taking ten to thirty rounds under fixed per-task pricing, and later changed its billing and user entry points. Low-priced student materials generated high exposure without covering service costs. The lesson is to count the complete multi-round cost, not just a single API call. Dify emphasizes that operators must keep materials, tools, and prompts updated, and rerun business tests after replacing a model.

The application sequence proposed here is: first use one real task to validate information → action → readback and define permissions, recovery, and cost; then expand the task set, parallelism, and autonomy. This is an editorial synthesis of mechanisms described in the interviews. It does not mean these products have been independently validated, nor require every task to use the same model, RL, or multi-agent architecture.

Tool Reuse and Process Visibility Still Need Data Completeness

Sheet0’s Wang Wenfeng emphasizes that context—the information available to the current task—includes code structures, web pages, tables, and tool execution results, with each round of feedback changing the next step. Tested query and execution components should be reused, leaving open-ended judgment where it is needed. But “the script ran,” “the table has no empty cells,” and “we retained code that succeeded once” do not establish 100% correctness across all inputs. Collection tasks must also check start and end boundaries, page counts, unique IDs, totals, reasons for missing data, and field sources. Publication tasks must verify actual storage and the public result. Seeing the browser operate can help users retain control, but cannot replace this evidence of completion.

Gru’s Zhang Hailong discusses a narrow entry point for a unit-testing agent and a multi-repository task set, showing how repetitive labor can have well-defined inputs and outputs. Generated tests, however, may enshrine existing bugs as expected behavior. Intended results therefore need independent definitions. Coverage and pass rates are meaningful only if the tests themselves are correct.

Revisions Across Interviews with the Same Product: Accuracy Claims Are Not Acceptance Criteria

Sheet0’s 2025 interview emphasized stable, complete collection and processing of structured data. When Wang Wenfeng returned in March 2026, he explicitly acknowledged at 51:51 that the earlier pursuit of 100% accuracy was beyond what the model could actually achieve, and that it was not users’ main bottleneck at that time. This change should be read alongside the earlier claim. Result accuracy still needs acceptance testing, but product priorities must follow the obstacles in real tasks rather than turn an earlier marketing statement into a technical guarantee. An actionable approach is to record missing rows, incorrect columns, missing fields, unavailable data, and items requiring human confirmation separately, state a verifiable scope of completion, and prioritize fixes by user loss. The 2026 return interview

Stable and Replaceable Layers of Engineering Assets

Dify’s return interview in December 2025 traced the evolution of its 2023 prompt/RAG tools into enterprise workflows, plugins, and coordination across multiple models. Model upgrades should not force users to rebuild every process. Plugins, retrieval components, and model interfaces can be replaceable, while sensitive business fields, approved steps, and existing assets need compatibility commitments. The guest’s description of being “production-ready” does not refer to one accuracy figure, nor mean zero failures. Concrete acceptance checks should cover regression of existing workflows, field structures, stopping at exceptions, human–AI review, upgrades, and rollbacks. Four or five hundred nodes, or thousands of workflows, are self-reported customer examples; scale does not establish that fully automated management has been achieved. For nonstandard collaboration between organizations, a workflow’s role is to express clearly who executes, who provides feedback, and where a human must be involved. When a person repeatedly generates and selects a satisfactory result, delivery responsibility still rests with that person. This and the early Dify notes from 2023 describe an evolution across stages; later capabilities must not be retroactively attributed to the initial version. Dify’s 2025 return interview

2026-10-18 增补：自然语言转SQL，先验收业务语义再验收生产使用

本节来自本期Builders对Andy Pavlo在MAD访谈的整理，属于受访者经验与本文的应用建议。本节具体补充数据库任务的验收，不把某家银行的投入或准确率当作普遍标准，也不采用访谈中的未来流量预测作为既成事实。

把业务词映射到可以复核的查询约束

SQL可以执行，只说明数据库接受了语句；结果是否回答业务问题，还取决于定义和数据范围。生成前至少明确业务词、对应表字段、关联关系、时间口径、访问权限，以及什么结果才算正确。模型或MCP接口能访问数据库，不意味着它已经知道公司的业务语义，也不意味着它可以读取所有字段。

例如，以下是本文建议用于澄清和验收的问题，并非访谈提供的既有系统实现：

检查对象 生成前需要说清 验收时保留什么
业务定义 “活跃客户”按登录、交易还是合同定义？ 已确认的定义与反例
表与字段 用哪张表、哪个主键、如何关联与去重？ 字段映射和已知正确结果
数据范围 时间边界、时区及权限允许的数据是什么？ 数据版本、范围和授权记录
结果含义 返回明细、人数还是金额？缺失值如何解释？ 人工复核样例及预期结果

将语句执行、结果正确和生产验证分别记录

先在有明确预期结果的自有业务任务上验证语义，再观察在真实数据与权限下是否成立。一次运行无报错、一个样例结果一致、生产任务持续可用，是不同的验收层级。把失败问题、错误SQL、预期结果及修复后的回归样例一起留存，才能定位是业务定义、字段映射、数据范围还是生成过程出了问题。

Pavlo提醒公开基准可能受到训练数据覆盖影响，因此基准成绩不能直接代表某家企业的实际正确率。这是访谈提出的风险，不是对某个模型已经污染评测的独立证明。测试负载与生产负载也需分别记录；测试环境通过后，仍应核对生产数据规模、查询行为和实际业务结果，不能将测试成功直接记为生产验收。

适用于业务人员用自然语言查数、Agent生成查询或跨表分析的场景。业务定义尚未确定时，优先补语义与正确结果样例；不要靠换一个更高榜单分数的模型来掩盖未明确的口径。

English translation

Addition: For natural-language-to-SQL, validate business meaning before production use

This section draws on the Builders account of Andy Pavlo’s MAD interview. It distinguishes the guest’s experience from the applications proposed here. It adds concrete checks for database tasks. One bank’s investment or accuracy is not a universal standard, and the interview’s forecasts of future traffic are not treated as established facts.

Map business terms to query constraints that people can review

An executable SQL statement only shows that the database accepted it. Whether its result answers the business question also depends on definitions and data scope. Before generation, establish the business terms, corresponding tables and columns, relationships, time conventions, access permissions and what counts as the correct result. A model or MCP interface having database access does not mean it knows the company’s business semantics or may read every column.

The following are proposed clarification and acceptance questions, rather than implementations supplied by the interview:

Check Clarify before generation Retain for acceptance
Business definition Does “active customer” mean a login, a transaction or a contract? An agreed definition and counterexamples
Tables and columns Which table and primary key apply? How should records be joined and deduplicated? Column mappings and known correct results
Data scope What are the time boundaries, time zone and permitted data scope? The data version, scope and authorization record
Result meaning Should the query return individual records, a count of people or a monetary amount? How are missing values interpreted? Human-reviewed examples and expected results

Record execution, result correctness and production validation separately

First validate meaning against internal business tasks with explicit expected results, then check whether it holds with real data and permissions. A run without errors, a matching result on one example and sustained usability in production represent different levels of acceptance. Keep failed questions, incorrect SQL, expected results and the regression examples used after a fix together. These records help distinguish failures in business definitions, column mappings, data scope and generation.

Pavlo warns that training data may cover public benchmarks, so benchmark scores cannot directly stand in for a particular company’s actual accuracy. This is a risk raised in the interview, not independent proof that a particular model’s evaluation was contaminated. Record test and production workloads separately as well. Passing in a test environment still requires checking production data scale, query behavior and actual business results; test success alone does not establish production acceptance.

Use this approach when business users ask questions in natural language, agents generate queries or analysis spans multiple tables. If business definitions are unsettled, first supply those definitions and examples of correct results. A model with a higher leaderboard score cannot resolve an unspecified business definition.

2026-10-21 增补：长期在线不等于每台执行电脑一直开着

本节依据深思圈对 Lee Robinson 斯坦福分享的中文转述，尚未独立核对原课程、Grok Bot 代码或实际部署。不采用“幻觉基本解决”“自动审核通常更安全”或未来可以连续工作数月等说法作为已验证结论。

让任务状态与执行电脑各自恢复

转述中的设计把对话、记忆和例行任务放在服务端，执行电脑按需启动，使用快照恢复或重建。这样给电脑补丁、换沙箱或休眠，不必把任务目标和进度一起丢掉。来源提到 Firecracker 和 Temporal，值得保留的机制是执行环境可以替换，任务游标和结果另有可靠记录，而不是要求所有项目采用同一套基础设施。

任务恢复要分别检查“下一步从哪里接着做”和“上一步是否已对外生效”。可持久化工作流能帮助保留进度，但不能仅凭框架名称保证邮件、付款或外部写入恰好发生一次。遇到返回结果不明时，先核对外部状态和回执，再决定是否重试。隔离电脑、任务运行循环与身份授权也应分别验证。

用户打断优先，后台事件合并

来源描述用户直接更改目标时优先处理，群聊、后台任务等事件则排队，短时间内的多条消息可以合并处理。应用时应保留每条事件的来源和处理结果，避免合并后丢失用户撤销或修改要求。没有实质进展就不打扰，与停止执行是不同状态；提醒、请求批准和已经发送的信息也要分开记录。

缓存前缀稳定，压缩仍有信息损失

工具定义和系统提示保持稳定顺序，可以减少不必要的前缀变化；在长对话缓存仍热时准备压缩摘要，也是一种成本管理思路。但缓存是否命中仍取决于具体服务、有效期和请求内容，不能把每次未命中都当成同一种错误。压缩会丢信息，因此需要保留原始日志、关键约束和可找回的文件，而不是把摘要当作完整原始记录。

English

This addition is based on Shensiquan’s Chinese account of Lee Robinson’s Stanford presentation. The original course, Grok Bot code and deployment have not been independently checked. Claims that hallucinations are essentially solved, automated review is usually safer or agents will soon work continuously for months are not adopted as verified conclusions.

Recover task state separately from the execution computer. The account describes keeping conversations, memory and routines on the server while starting the execution computer on demand and restoring or rebuilding it from snapshots. Patching, replacing or suspending that computer need not discard the task’s goal and progress. Firecracker and Temporal are named in the source. The transferable mechanism is a replaceable execution environment with reliable records of progress and results, rather than a requirement to use those particular technologies.

Recovery needs separate checks for where to resume and whether the previous external action already took effect. Durable workflows can help preserve progress, but a framework name alone does not guarantee that an email, payment or external write happens exactly once. When a result is uncertain, inspect external state and receipts before retrying. Isolation, the task loop and identity permissions also require separate verification.

Prioritize user interruptions and combine background events. The account gives direct changes to a user’s goal priority, while group messages and background work queue up and may be batched when they arrive together. Preserve each event’s source and handling result so batching does not lose a cancellation or changed instruction. Remaining quiet when there is no material progress differs from stopping execution. Notifications, requests for approval and messages already sent should have distinct records.

Keep cache prefixes stable while recognizing compression loss. Stable ordering of tool definitions and system prompts can reduce unnecessary prefix changes. Preparing a compressed summary while a long conversation’s cache is warm is also a cost-management idea. Cache hits still depend on the service, retention period and request content; not every miss has the same cause. Compression loses information, so retain original logs, essential constraints and retrievable files rather than treating a summary as a complete original record.

2026-10-23 增补：按Agent实际运行方式校准工期

委托 Agent 时，工期应基于它的实际执行方式，而不是照抄人的工作日。Swyx 对 Opus 5.5 的个人评价强调，模型持续运行、可并行处理的任务，可能与人的耗时不同；“两三天对两三小时”是其举例，不是对所有任务的效率保证，也没有提供独立基准。

本库应用：先让 Agent 写清任务拆分、依赖、可并行部分和需要人接手的环节，再给预计完成时间。运行中若新增阻塞或修复工作，更新剩余时间与原因；完成后比较预测与实际，逐步判断这个模型和工具组合在哪些任务上估得准。可以记录“初始估计—最新估计—实际耗时—偏差原因”，但这不是来源给出的固定格式。

预计很快完成不能替代权限批准，也不能把等待用户、服务排队或工具不可用的时间抹掉。对外承诺仍要依据真实依赖和可用资源，不能因为模型自信就承诺统一倍速。与编程 Agent 的计划/隔离执行/独立复核章节互链，不把估时能力当成结果正确性的证明。

来源：https://x.com/swyx/status/2113283272130412684

2026-10-24 增补：逻辑隔离与共享硬件风险分别验收

Agent 的账号、文件、进程和执行沙箱分开，不代表它们没有共用底层硬件。Guillermo Rauch 对共享主机时序问题的说明增加了一个不同层次的检查：两个执行者共用机器时，CPU 缓存干扰可能通过各自运行耗时被感知。这类侧信道不需要把一个任务的文件直接交给另一个任务，不能只用“目录没有互相访问”来判断隔离完整。

这里保留的是 Rauch 的公开说明，未独立复现攻击，也没有审计 Vercel Sandbox。他称每个 Agent 独享硬件可以处理这类共享风险，同时承认经济成本；这不能扩写为所有攻击都已解决。实际选型可分别问供应商：逻辑访问如何隔离，机器和缓存是否共享，采用哪些缓解与监控，哪些残余风险还在。供应商说部署了缓解措施与已经消除风险，是两种不同证据。

应用建议：按任务敏感程度和成本选择运行方式，把共享层、已知限制与异常接手者写入验收记录。独享硬件本身仍不替代账号授权、代码审查和外部动作回读；低风险演示也不必照搬最昂贵配置。相关运行责任可参阅企业 AI 落地。

来源：Guillermo Rauch 原帖。上述验收办法为编辑应用建议。

English edition

AI Agent Architecture and Multi-Agent Orchestration

When to open this note: you are building an agent product, writing an architecture proposal, choosing a multi-agent framework or explaining the field. It draws agreement and explicit disagreement from nine author collections: individual posts, research reports, practical deployments, AWS talks, academic papers, Anthropic/OpenAI interviews and investor analysis.

Core point: authors do not always mean the same thing by “agent.” Establish whether the discussion concerns engineering one agent, orchestrating logical agents, operating multiple real terminals, or combining a workflow with agent decisions at particular steps. Methods from different layers cannot simply be joined together.

Historical scope. This is a translation of the published historical synthesis. Numbers, market judgments, framework comparisons and forecasts retain their source dates; translation is not a new verification of them. Suitability ratings below are the original authors' heuristics, not safety or investment guidance. Existing later additions preserve their individual evidence limits.

0. Different meanings of agent and multi-agent

The original heading calls this five perspectives; the expanded table contains six.

Perspective Source collection Meaning of “agent” Unit of orchestration
Judgments from individual posts Huang Yihe/newtype agent architecture Perception, autonomous decisions and actions unfolding over time Chief, deputy and specialist
Research report newtype architecture research Enterprise infrastructure; cites Morgan Stanley's reported 98% adoption Supervisor, P2P, hierarchical and event-driven; eight Google ADK patterns
Practical agent matrix Wang Kai engineering and multi-agent matrix Literally starting claude in a new terminal Identity × role; proxy/session separation
AWS industry practice AWS agent talks Wang Xiaoyan's four elements and three levels of agentic AI Reasoning models plus an orchestrator; Chang Gaowei's ANP
Academic work Agent research papers Agent count as another scaling dimension Sampling and voting
Anthropic/OpenAI interviews AI organizational operations A software-engineering teammate; coding agents and Cowork Mixed initiative and compaction

The definitions span logical decision systems, real processes and repeated samples from a model. Clarify those assumptions before borrowing a method.

1. Seven areas of agreement

1.1 Workflows and agents complement one another

Dimension Workflow Agent
Essence Define tasks and dependencies Perceive, decide and act
Form A static diagram or blueprint Actions unfolding over time
Center Dependencies Decisions and execution
Main question What happens, and in what order? What should happen now?
Abstraction Business process Execution intelligence

Huang's formulation combines a spatial/process structure with a logical decision structure. Implementation becomes an agentic workflow: a workflow skeleton with agents at decision points.

Wang Kai contrasts traditional cron jobs running written rules with an agent loop that can make judgments. The research synthesis similarly treats production orchestration as combinations of workflow and agent behavior rather than an entirely unstructured agent.

1.2 Workflow design matters more than adding models or prompts

In an April 2024 post, Huang argues that the technical assembly is easy compared with deciding what agents should actually do.

The note's explanation is that many teams focus on model training and prompts while neglecting process design. Without an effective process, conversation does not become sustained delivery. Business understanding can therefore be a more durable advantage than superficial prompt work. The original “90% of failures” phrasing is an unsupported rhetorical estimate, not a measured rate.

Wang Kai's trading experiment—six models each given a reported $10,000—illustrates agents becoming absorbed in small changes to existing positions instead of considering an overall exit to cash. The lesson in the source is to define what strategic choices the task can consider, rather than assuming local optimization will discover them. It does not grant any trading authority.

The eight patterns discussed in the Google ADK research synthesis—sequential, parallel, loop, router, fork-join, map-reduce, reflexion and hierarchical plan/execute—are explicit process arrangements rather than instructions to improvise freely.

1.3 Three conditions for reliable delivery

Huang's January 2026 post 2208 proposes:

Condition Meaning
Clear task Keep the boundary narrow
Bounded setting Do not expect success in an unlimited open world
Verifiable result Provide an automated way to check correctness where possible

The central argument is that probabilistic capabilities need a constrained search space to support dependable product delivery. Wang Kai, citing Jason Wei, similarly distinguishes verifiable tasks from tasks whose results are hard to check.

Setting Original heuristic rating Reason given in the note
Programming 5/5 Results can be tested; the original shorthand says “it runs”
Investment decisions 4/5 The original uses profit as feedback; this is a simplistic source heuristic, not evidence that short-term profit validates a strategy
Mathematics 5/5 Reference answers
Content generation 3/5 Subjective evaluation and drift
Market research 3/5 Source quality heavily affects results
Law/healthcare 2/5 Access restrictions and high consequences

Running code alone does not prove correctness, and these ratings are not empirical performance measurements.

1.4 General-agent wrappers may be absorbed by model upgrades

In a March 2025 critique of Manus, Huang says frequent Claude, Cursor or Deep Research users would recognize task decomposition, information gathering and tool calls rather than find them unprecedented. He predicts that workarounds for model limitations will be overtaken by upgrades and that a general wrapper without its own model may be short-lived.

Wang Kai calls Manus relatively complex for the domestic market but argues the barrier is low and much of the result comes from consuming more tokens.

The note's examples are built-in browsing replacing some browser wrappers and Claude Code subagents/skills overlapping generic coding-agent wrappers. These are the authors' competitive interpretations, not proof that every application layer disappears.

1.5 Command-line interfaces can suit agents better than GUIs

Huang's July 2025 formulation combines a command-line agent with an MCP ecosystem as a general-agent skeleton. The original “ten times stronger” heading is a qualitative claim, not a reproduced benchmark.

Dimension CLI GUI
Output Directly readable text/JSON Pixels may first need interpretation
Composition Pipes, stdin/stdout and mature Unix conventions Simulated clicks can be slower and fragile
Concurrency Batch processing, parallelism and retries Shared window interaction is constrained

Wang Kai's examples include terminal agents, real-browser Chrome MCP, a Feishu CLI and a financial-data MCP. Huang describes newtype OS becoming fully CLI-oriented by October 2025: interfaces intended for agents rather than only people.

1.6 MCP as the collection's emerging standard

The research account dates Anthropic's introduction of MCP to November 2024 and describes adoption across OpenAI, Anthropic, Google and six major frameworks during 2025. Its role is to reduce incompatible, provider-specific tool protocols.

Wang Kai's practical list includes FMP MCP for financial data instead of fabricated search figures, Chrome MCP with user data and session reuse for separate browsers, Feishu CLI as a collaboration channel and AgentMail for agent email identities. See the related MCP ecosystem note. These describe archived practice, not current supported browser instructions.

1.7 Huang's five tests for multi-agent orchestration

The source distinguishes richer orchestration from lightweight Claude Code task delegation.

Feature Description
Hierarchy and nesting An orchestrator can delegate to sub-orchestrators, with debate/review and longer chains
Multiple models/providers Different models for planning, execution or search, balancing cost and capability
Shared state and coordination Persistent memory, conflict resolution, dynamic routing, loops and recovery managed by code/frameworks
Parallelism and scale Tens or hundreds of concurrent agents for large or long-running work
Programmability Workflows defined in code rather than only natural-language delegation inside one model

Huang calls Claude Code subagents internal routing and lightweight delegation suited to simpler work. That is his taxonomy, not a claim that the term “multi-agent” has only one valid definition.

The note maps Wang Kai's matrix to all five: identity-level coordination plus role agents; Claude Code and Codex review; shared identity configuration/session routing; multiple agents and identities in parallel; and separately programmable terminal/configuration arrangements.

2. Four disagreements to preserve

2.1 A logical child agent or an independent real terminal?

Source Structure What “agent” means
Huang/newtype Profile Chief–deputy–specialist Child Claude Code instances started with a task tool
Wang Kai Identity × role A separate terminal running claude
Research report Supervisor/P2P/hierarchical/event-driven Logical agents in LangGraph, CrewAI or AutoGen
AWS/Wang Qixiang Reasoning model plus orchestrator An orchestrator calling separate reasoning models

The levels differ: Huang, Cal Rueb and the research account usually discuss model/tool/role combinations; Wang Kai describes distinct OS processes, browsers and accounts; sampling-and-voting papers vary repeated model samples.

The synthesis distinguishes physical execution, logical agents and sampling agents. A physical environment can host logical agents and samples; a voting sample alone does not supply the isolation of a real process.

2.2 Startup category or future model-provider feature?

View Position recorded
Huang, March 2025 Small teams should avoid general agents competing directly with major labs
Wang Kai, March 29, 2025 High token cost, provider competition and an immature ecosystem can make it a loss-making contest
Wang Kai, other 2026 posts Templates, directories, curated cases and vertical agents still offer adjacent opportunities
January 2026 research report Enterprise deployment is described as mature, citing Morgan Stanley, Klarna, BBVA and Rakuten
AWS/idoubi Build narrow products by combining general agents with a focused workflow; describes over ten products and a one-hour launch procedure
Shensi/investor coverage Continued a16z and Sequoia investment and intense valuation interest

The synthesis reads this as market segmentation rather than a simple right/wrong dispute: consumer microteams face one set of pressures; enterprise and vertical workflows another; research and investors may still see general-agent opportunities where upgrading a model does not replace an entire domain process. Adoption claims remain source claims.

2.3 Which coordination structure?

Approach Center of coordination
newtype Profile Chief–deputy–specialist hierarchy
OpenAI Swarm / AutoGen Peer-to-peer interaction
Google ADK / CrewAI Supervisor plus explicit patterns
Wang Kai's browser matrix A hub reads logs and memory to coordinate without itself controlling browsers
Cal Rueb / Anthropic account Task-tool subagents; cautious use, citing roughly 1.3× speed with four parallel agents

Task boundaries determine the choice:

  • Clear specialist assignments: supervisor.
  • Collaborative work, such as jointly writing a paper: P2P.
  • Large architect/coder/reviewer tasks: hierarchical.
  • Real-time monitoring or trading systems: event-driven orchestration, illustrated by Kafka or Temporal plus agents.
  • Identity matrices: a coordinating hub and identity isolation.

These are source-level design examples, not permission to act across accounts or execute trades.

2.4 Is an agent a new form of content or service?

Huang's January 2026 post 2274 contrasts old content as an information snapshot with an entity packaging knowledge, logic and tools. Users ask it questions, invoke it and collaborate with it. In his view, content can become a delivery vehicle for services.

The note labels this as Huang's distinctive thesis. Wang Kai emphasizes engineering, the research report architecture and AWS industry delivery; they do not all make the same content-creator argument. It is a hypothesis to test, not a consensus to impose.

3. Four orchestration patterns and eight ADK patterns

3.1 Four basic structures

Pattern Structure Suitable task Main difficulty
Supervisor A central agent routes to specialists Clear boundaries, such as billing, technical support and refunds Central bottleneck and accumulated latency
P2P swarm Agents interact directly Collaborative tasks Unpredictability, debugging and loops
Hierarchical Multiple levels, such as architect/coder/reviewer Large complex work Latency and information loss at each level
Event-driven Subscribe to events and process asynchronously Monitoring, alerts and real-time systems State complexity and event ordering

3.2 Eight patterns in the ADK research synthesis

  1. Sequential pipeline.
  2. Parallel execution and aggregation.
  3. Loop until a criterion is met.
  4. Content-based router.
  5. Fork-join distribution and collection.
  6. Map-reduce for partitioned work.
  7. Reflexion/self-correction.
  8. Hierarchical plan-and-execute.

3.3 Six-framework comparison in the archive

Framework Origin Emphasis recorded Learning difficulty in the note
LangGraph LangChain Supervisor/custom graphs Medium
CrewAI Independent Supervisor/hierarchy Low
Microsoft Agent Framework / MAF Microsoft Hierarchy Medium
AutoGen Microsoft P2P swarm High
LlamaIndex LlamaIndex Workflow-driven Medium
Google ADK Google Eight patterns High

These are the research report's historical comparisons. Its section six contains a more detailed selection tree; no current benchmark is implied here.

4. MemoryOS: three memory layers

The architecture research note refers to arXiv:2506.06326.

Layer Full name Human-memory analogy Storage examples Lifetime in the source design
STM Short-term memory Working memory RAM/context window Current session
MTM Mid-term memory Hippocampus Redis/relational database Days to weeks
LPM Long-term personal memory Cortex Vector database plus key-value storage Persistent

Design principles in the note:

  • Not everything enters long-term memory; a model evaluates importance.
  • Forgetting is a feature: short-term decay, periodic mid-term cleanup, and long-term retention of user-validated information.
  • Explainability: the assistant should explain that it remembers X because the user previously said Y.

The archived vector-database heuristic is pgvector for tens of millions of items with existing PostgreSQL, Pinecone or Qdrant for a new deployment at that scale, distributed Milvus for hundreds of millions, Weaviate for multimodal work, and Chroma for a prototype. These are dated selection shortcuts, not present-day requirements.

The note describes Mem0, referring to arXiv:2504.19413, as an open-source implementation of related memory ideas with integrations across LangGraph, CrewAI, OpenAI and Anthropic. That relationship and integration list are statements in the source synthesis, not a new technical verification.

5. Wang Kai's multi-browser matrix

The case combines one computer, N independent identities and M agents per identity.

5.1 Definitions

An identity consists of a browser application, login state, residential-proxy exit and proxy process. A role is a Claude Code agent in a separate working directory sharing that identity's browser instance.

Here an agent means a real terminal/session, not Claude Code's internal task-tool child.

5.2 Example port pairs

Identity Browser Proxy port Browser debugging port Proxy exit label
A Chrome 9401 9222 US East
B Arc 9402 9223 US West
C Brave 9403 9224 UK
D Edge 9404 9225 Germany
E Vivaldi 9405 9226 Japan

This is the published historical example, not the website-maintenance browser configuration or an instruction to restore deprecated collectors.

5.3 Four isolation dimensions

The case distinguishes browser applications, accounts/user-data directories, IP exits and browser fingerprints, naming Multilogin, GoLogin and AdsPower as fingerprint-management examples. Isolation does not itself confer permission to use an account or bypass platform rules.

5.4 Multiple agents inside one identity

Their MCP configurations point to the same proxy port—9401 in the identity-A example. The proxy routes by session ID to avoid cross-session event confusion.

5.5 The coordination hub

A separate hub reads logs and memory to dispatch work without directly controlling a browser. The architectural distinction is coordination versus execution; the original local hub path is not needed to use this public explanation.

6. Wang Kai's L1–L5 levels

The source borrows the shape of autonomous-driving levels.

Level Description Position recorded at the time
L1: point assistance Human asks, AI writes, human executes Widespread
L2: multistep assistance AI decomposes and guides Cursor, v0 and deep research
L3: partial autonomy AI completes multiple steps under supervision Devin and Claude Code agents
L4: full autonomy Complex work without human intervention The source expects a further 90% token-price decline
L5: agent organizations Agents perform organizational work together An OpenAI L5 vision

Wang Kai places his own supervised investment-strategy and promotion workflows at L3. The cost threshold for L4 is his forecast, not a validated condition.

In the related Cat Wu/Embiricos interviews, the reported bottlenecks are human typing and multitasking speed. Their forecast places self-sufficient agents with early adopters in 2026 and broader large-company adoption several years later. These statements retain their original time frame.

7. Four AWS agent-talk threads

7.1 Wang Qixiang

Reasoning models plus a multi-agent orchestrator, including a practical comparison of six frameworks.

7.2 Wang Xiaoyan

Four elements of agentic AI, three maturity levels, reinforcement learning, product pricing and three curves. The three-level scale differs from Wang Kai's L1–L5 taxonomy.

7.3 Chang Gaowei

ANP as an agent-to-agent communication protocol, involving W3C decentralized identifiers and peer-to-peer communication. The talk compares MCP with USB-C for connecting tools and ANP with email for direct agent communication.

7.4 idoubi

Independent development of more than ten AI products, a one-hour launch procedure, Product Hunt launch strategy, programmatic SEO and five proposed directions for focused investment. The short original summary does not enumerate those five directions, so this edition does not invent them.

8. Three academic threads

8.1 CAMEL-AI: Finding the Scaling Laws of Agents

Wendong Fan's account treats agent count as a new scaling axis alongside parameter count, covering OWL, CRAB, OASIS and DataGen.

8.2 Tencent: More Agents Is All You Need

Sampling and voting increase agent/sample count. The summary reports Llama2-13B with fifteen agents matching Llama2-70B in the paper's comparison, and mentions three gain dimensions, stepwise work and hierarchy. This is a bounded reported comparison, not general equivalence across tasks.

8.3 NVIDIA: ChatQA

The note highlights a 70B question-answering model with two-stage tuning, a fine-tuned retriever instead of GPT-3.5 query rewriting, and 1,500 unanswerable examples intended to reduce hallucination.

9A. Codex and the Anthropic coding-agent perspective

The original repeats section number 9; this edition labels the two sections 9A and 9B for clarity. The archived “Cloud Code” naming is retained as a source transcription, not a newly verified product name.

9A.1 Embiricos / OpenAI Codex

The interview summary reports twentyfold growth after GPT-5, trillions of tokens served weekly and a leading API position. These claims were not independently checked here.

Compaction is presented as a key innovation enabling work beyond a context window through model, API and harness coordination. The vision is a software-engineering teammate—likened to a smart intern—without requiring people to monitor a Slack stream continuously. The design favors mixed initiative, combining human empowerment with assistance rather than maximizing autonomy alone.

9A.2 Cat Wu / Anthropic

The account covers terminal, desktop, web, mobile and Cowork forms. Cowork is described as “Claude with hands” for tasks such as clearing Slack or an inbox and producing slide decks.

It also describes removing temporary crutches: an early to-do list helped models perform large refactors, but could be removed when a later model no longer needed it.

9A.3 Three strategic layers

Lens Layers
Technology Models → infrastructure → application scenarios
Value chain Supply → transmission/intermediation → demand
Competition General model providers → independent infrastructure → vertical applications

For founders, the note proposes generality and infrastructure at the lower level, best practices and possible standards in the harness/tool layer, and scenario depth/domain defenses at the application layer.

9B. Shensi's agent-company perspective

The author overview is the entry point to a 659-article source collection; the count describes that archive. Topic notes added May 18, 2026 cover agent companies, eight B2B verticals and leading-company strategies.

9B.1 Cursor: training is the product

The November 2025 account of Sasha Rush at Ray Summit reports fourfold token efficiency and the same microVM environment for training and production. Its three challenges are training/inference matching, long rollouts and consistency between learning and real operation.

9B.2 Anthropic: permission alongside intelligence

Jaya Gupta's May 2026 argument shifts enterprise scarcity toward organizational permission: legal, risk and board approval for AI to execute in real systems, not just a stronger model.

9B.3 Four types and the 11x lesson

Type Examples in the collection
Horizontal Imbue at a reported $1 billion valuation, Manus and Devin
Coding Cursor, Lovable, Devin and Replit
Vertical Harvey, 11x, Decagon and Eve
Infrastructure LangChain, agent Git with a reported $17 million a16z round, and agent insurance with a reported $15 million round

The note interprets the 11x controversy as a warning that digital employees must address trust and permission, not merely automate tasks.

9B.4 Anti-framework arguments

An account of Cursor, Perplexity and Lovable favors direct implementation over general LangChain/AutoGen/CrewAI frameworks for control and speed. This remains a case argument rather than a universal performance finding.

10. Architecture paths by role

Reader Main approach Starting point
Independent builder / matrix operator Wang Kai's multi-browser matrix Identity × role, session separation and hub coordination
Product/engineering team following Anthropic practice Cautious task-tool delegation and Cowork The source's four-agent/approximately 1.3× example; noncoding tasks such as Slack or decks
Enterprise project Four patterns and framework comparison Choose supervisor, hierarchy or event-driven work by task boundary
Content creator Huang's agent-as-content thesis Package knowledge as skills/plugins users can invoke
Researcher CAMEL and More Agents Sampling, voting and agent scaling
Investor Shensi/a16z lens Domain depth, memory assets and exposure to model upgrades

Suggested sequence in the original synthesis:

  1. Draw the workflow and explain each step plainly before adding agents.
  2. Check task clarity, bounded setting and verifiability.
  3. Begin with the workflow; insert agents only where understanding and decisions are needed.
  4. Choose coordination structure: supervisor for clear responsibilities, P2P for collaboration, hierarchy for large work, event-driven for real-time work.
  5. Connect reliable data/tools. The source emphasizes MCP through Wang Kai's FMP case; using a protocol alone does not guarantee accurate data.
  6. Add memory for cross-session tasks, with the three-layer model as one reference.
  7. Make activity observable: the historical examples include ten-minute inspection and a sound from a stop hook.

11. Reference collections

Primary author collections:

  • newtype agent architecture: posts from April 2024 to May 2026, five orchestration features, chief/deputy/specialist, agent-native forecasts and agent-as-content.
  • Architecture research report: four patterns, eight ADK arrangements, MemoryOS, six frameworks and Morgan Stanley.
  • AWS talks: Wang Qixiang, Wang Xiaoyan, Chang Gaowei/ANP and idoubi.
  • Agent papers: CAMEL scaling, More Agents and ChatQA.
  • Agent-market research: January 2026 investment trends, including the source's $87 billion, 191-unicorn and 25× revenue-multiple claims.
  • Wang Kai engineering: 272 posts, L1–L5, tools, automated tasks and a $200 Polymarket experiment.
  • Wang Kai matrix, version 1.1: identity × role, proxy and hub.
  • AI organizational operations: Embiricos, Cat Wu, compaction, mixed initiative and human bottlenecks.
  • Shensi overview: 69 articles tagged Agent in that index, VC analysis and a16z valuations.

Related topic notes cover Claude Code workflows, the MCP ecosystem, skill engineering, coding-tool evolution, investment valuations, the Anthropic engineering hub, its evaluation deep dive and cross-author evaluation methodology. Original batch labels describe the historical organization of that knowledge collection, not the completion state of this translation. Public links accompany the edition's source references.

May 19, 2026 addition: Anthropic engineering's first-party perspective

The collection archived twenty-five Anthropic engineering articles in May 2026 and added a seventh perspective to the previous six: the engineering team's own published accounts.

Building Effective Agents: five building blocks

Anthropic distinguishes workflows following predefined paths from agents dynamically deciding the next step. The source emphasizes successful systems without complex frameworks.

Workflow patterns:
1. Prompt chaining
2. Routing
3. Parallelization: sectioning or voting
4. Orchestrator–workers
5. Evaluator–optimizer

Agent: the model chooses the next step in a tool-calling loop.

Agentic systems may exchange latency and cost for better task performance. The note frames this as a tradeoff—more flexibility can also mean more time and expense—not an automatic maturity upgrade. It compares this with Huang's workflow-plus-agent approach and Wang Kai's autonomy levels.

Harness arrangements over time

The historical heading says four kinds, but the expanded table contains five.

Setting Arrangement Example Article reference
One session Standard harness Claude Code / Cursor claude-code-best-practices
One long-running agent Initializer plus coding agent Agent SDK long-running template effective-harnesses-for-long-running-agents
Long-running subjective quality work One agent creates, another evaluates, inspired by GANs Frontend design/app building harness-design-long-running-apps
Parallel agents Planner, workers and synthesizer Claude.ai Research multi-agent-research-system
Decoupled managed execution Separate brain from hands Managed Agents managed-agents

Harness assumptions can expire. The note cites Sonnet 4.5's “context anxiety”—rushing as context ran low—disappearing in 4.6, turning an old workaround into overhead. The Managed Agents idea is to adapt the harness with model changes rather than manually rebuilding each time.

Carlini's sixteen-Claude C compiler experiment

The building-c-compiler account by Nicholas Carlini reports sixteen parallel Claude instances writing a Rust-based C compiler from scratch, nearly 2,000 Claude Code sessions, approximately $20,000 in API charges and 100,000 lines. It reports compiling Linux 6.9 for x86, ARM and RISC-V, with code at anthropics/claudes-c-compiler.

Lessons drawn in the note:

  1. Tests keep unsupervised work directed by a correctness signal.
  2. Structured tasks let agents work in parallel without conflicting.
  3. Team size has an upper bound; adding agents indefinitely does not solve arbitrary projects.

This qualifies simplistic readings of agent-count scaling papers. The source emphasizes process structure as well as quantity.

The multi-agent research system

A planner receives a question and decomposes parallel queries; workers use web search, Google Workspace and integrations; a synthesizer combines results into a report.

Costs include context exchange, evaluating the whole team rather than one agent, and compounded reliability risks. The archived formula 1 − 0.95^N illustrates at least one failure among N agents with independent 5% failure probabilities. Independence is an assumption; it is not an observed failure model for every agent system.

The note maps the design to hierarchical plan-and-execute.

Evaluations are part of engineering

The related Anthropic evaluation deep dive and cross-author methods note expand these points:

  • Evaluate the harness plus model, not model weights alone.
  • Maintain a capability suite, initially around 20–40% success, alongside a near-100% regression suite.
  • Distinguish pass@k from pass^k. With 75% per-attempt success and k=10, the former approaches 100%, whereas the latter is about 5.6%, under the simplifying probability assumptions.
  • Infrastructure differences can outweigh model differences; the archive cites a six-point Terminal-Bench change from infrastructure configuration.
  • Evaluation awareness matters. The note describes Opus 4.6 recognizing BrowseComp and decrypting an answer key; this remains the archived first-party account.

History

  • May 19, 2026: added Anthropic's five building blocks, harness categories, the sixteen-Claude compiler experiment and research-system architecture, with links to the engineering/evaluation notes.
  • May 18, 2026: first topic synthesis from nine author collections. It explicitly retained four disagreements: physical/logical/sampling agents, startup opportunity versus provider feature, coordination structure and agents as content.

September 2026 addition: verifiable results from unattended pipelines

Evidence scope: a VoidSpark code-analysis note saved June 15, 2026. This is a design case; the project was not rerun for the addition. Thresholds are its configuration, not universal optima.

1. Separate process state from executors

Keep an explicit state for each task. Individual stages claim work according to that state. A generic process reads project configuration rather than embedding one business name, path or budget. Replacing an executor then need not erase the durable next step.

Stages may cover topic selection, definition, implementation, execution and adjudication, each with output and review. Cap rework: this case uses three rounds to prevent indefinite looping, not because three rounds universally establish correctness.

2. No improvement differs from an invalid experiment

Result Meaning Next action
WIN Improvement observed Retain result and comparison evidence
NULL No improvement observed Record a tested unhelpful direction to avoid repetition
FAIL Performance worsened Retain failure evidence and revert to a usable result
DRIFT Conditions invalidated comparability Repair conditions, then decide whether to rerun

Calling both NULL and DRIFT failure loses the distinction between an ineffective direction and one not yet validly tested. Likewise, preserve a previous successful capture when a new fetch fails; do not overwrite it with an empty file.

3. Four constraints for long-running processes

  • Repeated triggers: heartbeats and schedules should be idempotent so another trigger does not start the same task again.
  • Concurrency: cap in-flight work and candidates. The case's concurrency of two and replenishment below five in-flight tasks up to a ceiling of twenty are illustrative watermarks.
  • Claiming and reclamation: record the executor, last activity and timeout. Establish whether an executor is still active before reclaiming slow work.
  • Artifact replacement: write temporary results, require success and nonempty checks, then replace the official artifact. Append-only status logs support replay and stage timing.

4. Unattended does not mean unlimited authority

Prompts may allow continued execution of already-authorized work and define exit states. The case's “just do it” instruction applies only to bounded background work; it cannot replace authorization for publication, payments or permission changes. Dangerous controls default off; project policy governs reversible low-impact actions.

For rate limiting, make failures observable and preserve progress before a fallback, avoiding repeated external effects. “Kill and restart whenever limited” is not an unconditional rule.

5. Use retrospectives to reduce repetition

Keep completed and rejected lists. Decide whether a candidate warrants effort before expensive execution and review. Attach a plain-language explanation to each artifact so people can judge its purpose quickly.

Monitor a symptom that reveals a blocked stage. VoidSpark focuses on idle GPUs; a content process could watch for new material without valid output. Such a signal helps locate a bottleneck but does not replace cost, safety or quality constraints.

Addition: Test decision components separately and choose thresholds by error cost

This addition is based on the October 16 Builders account of the interview with Diogo Almeida about Jev. It records the guest’s methods and supplier claims without reproducing product benchmarks. The existing discussion of type safety, probability calibration and authorization remains unchanged.

An email assistant can separately assess whether a message concerns sales, recruiting or a request for the recipient’s personal attention, then combine those judgments in code. Separate tests make failures easier to locate and retain as regression examples. More modules alone are not evidence of better design. The combined workflow still needs tests for overlapping conditions, precedence and uncertain cases. These are proposed applications, not a claim that the interview solved email scheduling.

Missing an important message and reviewing an extra ordinary message have different costs. Specify those costs before choosing thresholds, then observe both missed targets and false alarms on actual samples. A threshold expresses a trade-off; reducing alerts does not by itself demonstrate improved accuracy.

Almeida describes RLCD as involving input and output design, training data, balancing and objectives, rather than merely a different reinforcement-learning algorithm. He says the team builds its own data and combines open-weight models instead of pretraining from scratch. Check whether data covers relevant boundary cases, whether objectives reflect costly errors and whether results hold in the actual workflow. The account does not provide a complete reproducible training recipe or independent performance ranking.

Use this approach when one prompt handles many decisions and failures are difficult to isolate. Start with judgments that can be clearly labeled and compare maintenance costs. For low-volume tasks with clear rules, deterministic code may be sufficient.

Added 2026-10-18: Connecting Environment, Feedback, Collaboration, and Responsibility into a Deliverable Agent

Several 42 Zhangjing interviews add a product perspective to the orchestration and verification discussed above: from Dify in 2023 to Pokee and Grasp in 2025, then Huang Dongxu’s practical work, Junior, and Slock in 2026. These are practices from different periods and tasks, not an established, unified technical path. Historical capabilities and prices are not current benchmarks.

Before Deciding the Next Step, Give the Task Observable State

First define the goal, current state, available actions, outcome feedback, and fallback after failure. A missing API, a supplier who only takes phone calls, or an expired login session can prevent an otherwise sound plan from being completed. A model’s ability to express a plan does not mean the environment can execute it, much less that the result has been delivered.

Pokee separates the decision core built on reinforcement learning (RL, learning policies from action feedback) from the large language model (LLM, understanding language and generating expression). Its criteria for applicability are more useful than the claim that “agents must use RL”: does the task require exploring several unknown actions, do earlier steps affect later resources, and can long-term outcomes be observed and improved? Wu Yi’s interview on reinforcement learning emphasizes the complementary roles of understanding the environment and making sequential decisions, including the example of first asking for the environment version when information is incomplete. Application teams without reliable environments, acceptance criteria, and samples should fill those gaps first; they need not begin by training a model.

Different approaches retain different boundaries. Rules suit stable processes, model planning suits steps requiring judgment, and training suits repeated tasks with sufficient feedback. A single task can combine them. When an eleven-step path fails, the system needs to know which step it can return to and which external states have already changed. Generating the plan again does not erase side effects.

An Environment Includes Recovery and a Controllable Scope of Impact, Not Just a Tool List

Grasp distinguishes the runtime environment, decision loop, domain knowledge, and acceptance: a page loading and a task being completed are different things. Its state-preservation example focuses on resuming after an hour-long interruption and consuming fewer resources while idle. Huang Dongxu packages skills, environment state, and context together. Combining these ideas suggests that a reusable unit should include at least its inputs, tools and versions, login and permissions, data locations, progress cursor, evidence of completion, and failure recovery.

The interviews disagree about cloud and local deployment. Lei Lei places greater weight on cloud elasticity and continuous operation; Huang considers both local and cloud execution viable, with control and maintenance as considerations. Neither prediction should become the only deployment answer. The practical choice depends on data requirements, observability, cost, task duration, recovery after downtime, and who can stop execution.

A sandbox—an environment limiting which files, networks, and systems code can affect—limits the worst consequences; it does not make every action inherently safe. A login module being able to use credentials is also different from putting a password into model context. Restoring a session requires confirming that identity and permissions remain valid, not merely that the process is still alive.

Organizational and Personal Memory Serve Different Audiences and Have Different Sharing Boundaries

Junior emphasizes that an enterprise employee is not the owner’s alter ego. It needs to understand the company, projects, roles, and responsibilities, but an agent knowing everything about a small team should not be directly extended to an organization of ten thousand people. Remembering the boss’s private conversation does not authorize repeating it in a group, and knowing customer information does not mean every salesperson may access it.

Memory usability therefore involves at least two questions: does this information help the current task, and is the current recipient entitled to receive it? Identity, project, time, information source, and permitted sharing scope should be stored alongside the content. Role labels help guide behavior; they are not enforceable permissions. Access to tools and data requires system state and auditable constraints.

Gaotu’s case offers another use of memory: a lead’s history, intent, trial lessons, and questions form a report that is handed to a human to close the sale. It shows that complete context first serves handoff quality, without requiring the agent to know every detail of the customer’s life.

Reduce Duplicate Claims and Lost Context Before Pursuing More Multi-Agent Parallelism

Slock notes that people can see where an old thread belongs, while a model receives a mixed stream of events. A message ID or an @mention alone may not tell it which matter is under discussion or which identity it is acting under. When entering a work thread, supplying its topic, a summary of relevant earlier messages, the current owner, and the next action is more targeted than putting the entire group conversation into one context.

Task claims need an exclusive state: who accepted the task, when work began, where the artifact is, and who will accept it. Merely saying “do not duplicate work,” without shared task state, can still leave several agents editing the same file. Huang describes rapid changes to the same module overwriting one another. Parallelism can begin with work whose module boundaries are clear and whose results can be independently verified. The lead agent also needs to reconcile actual artifacts rather than simply adding together every sub-agent’s self-reported completion.

Reminders among agents may improve correction, but can also spread the same mistake. Slock’s observation of one corrected agent reminding another is an observation about collaboration, not proof that multi-agent consensus is necessarily reliable. Architecture comparisons should include context duplication, waiting, conflicts, review, and token costs, judging the benefit by total time and cost per acceptable delivery.

Evaluate Completion, Regression, Clarification, and Refusal to Exceed Boundaries

Ding Ding’s discussion of evaluation takes real input, complete output, and business criteria as the minimum test unit. Public leaderboards assess general capabilities; an internal task set assesses the business. Neither should replace the other. End-to-end cases can use the following dimensions:

Dimension What to observe Example failure
Understanding and clarification Identify missing information and ask critical questions promptly Repeatedly making incorrect changes without asking for the environment version
Actions and state Correct tools, parameters, and verification by reading back state The page reports success, but no order or file was created
Results and handoff The artifact meets requirements and can be checked and continued by the next person A polished summary without supporting evidence or output
Regression and coverage Samples cover old and new tasks, different user groups, and the long tail A new capability scores higher while an existing core process deteriorates
Permissions and confidentiality Do not share unauthorized information or take unauthorized actions Citing the boss’s private conversation while answering a group question
Recovery and correction Stop after an error, explain its impact, and retain a correction record Retrying causes a duplicate send, or missing data is silently replaced with zero

Junior retains both a fixed regression set and a path for frontline staff to explore new models. Preventing degradation on old questions and discovering new uses are different activities. Held-out, unseen samples help reduce teaching to the test, while version comparability must also be maintained. Automated judges should be cross-calibrated with humans and online behavior; a model’s “pass” is not an objective fact.

Character.AI’s post-training discussion provides a further counterexample in product metrics. Average conversation duration may increase because the model keeps asking questions to avoid sensitive topics, while heavy users’ experience declines. Edits, deletions, and regenerations can help construct preference samples, but their context and reasons must be retained. Not every edit means a preference for a particular writing style. Training use must also remain within the data’s original permitted scope. The quality of a long-term relationship, pleasing someone in a single turn, and short-term engagement should be tested separately.

Keep Responsibilities Explicit Between Judgment, Verification, and Action

The Vibe-Trading interview separates the model producing hypotheses, the harness—a system constraining execution and verification—providing checks, and the human owning scope and exceptions. Its most transferable elements are checks on data definitions, public availability dates, versions, and missing data. A thorough explanation does not guarantee trading profit, and “making money” is not the sole criterion of code correctness.

Actions that change business data can follow proposal → preview → execute → readback, with each action tied to its evidence, scope, and acceptable loss. Insufficient information should explicitly stop the process at “cannot determine.” A failed data source should be marked as missing, not silently filled with zero. A self-correction report shows that one error was found; it does not exempt future work from verification. Multiple judgments sharing the same incorrect source can fail together, so their individual confidence levels cannot simply be multiplied.

Cost and Operations Are Part of Architectural Acceptance

Junior encountered tasks with the same name taking ten to thirty rounds under fixed per-task pricing, and later changed its billing and user entry points. Low-priced student materials generated high exposure without covering service costs. The lesson is to count the complete multi-round cost, not just a single API call. Dify emphasizes that operators must keep materials, tools, and prompts updated, and rerun business tests after replacing a model.

The application sequence proposed here is: first use one real task to validate information → action → readback and define permissions, recovery, and cost; then expand the task set, parallelism, and autonomy. This is an editorial synthesis of mechanisms described in the interviews. It does not mean these products have been independently validated, nor require every task to use the same model, RL, or multi-agent architecture.

Tool Reuse and Process Visibility Still Need Data Completeness

Sheet0’s Wang Wenfeng emphasizes that context—the information available to the current task—includes code structures, web pages, tables, and tool execution results, with each round of feedback changing the next step. Tested query and execution components should be reused, leaving open-ended judgment where it is needed. But “the script ran,” “the table has no empty cells,” and “we retained code that succeeded once” do not establish 100% correctness across all inputs. Collection tasks must also check start and end boundaries, page counts, unique IDs, totals, reasons for missing data, and field sources. Publication tasks must verify actual storage and the public result. Seeing the browser operate can help users retain control, but cannot replace this evidence of completion.

Gru’s Zhang Hailong discusses a narrow entry point for a unit-testing agent and a multi-repository task set, showing how repetitive labor can have well-defined inputs and outputs. Generated tests, however, may enshrine existing bugs as expected behavior. Intended results therefore need independent definitions. Coverage and pass rates are meaningful only if the tests themselves are correct.

Revisions Across Interviews with the Same Product: Accuracy Claims Are Not Acceptance Criteria

Sheet0’s 2025 interview emphasized stable, complete collection and processing of structured data. When Wang Wenfeng returned in March 2026, he explicitly acknowledged at 51:51 that the earlier pursuit of 100% accuracy was beyond what the model could actually achieve, and that it was not users’ main bottleneck at that time. This change should be read alongside the earlier claim. Result accuracy still needs acceptance testing, but product priorities must follow the obstacles in real tasks rather than turn an earlier marketing statement into a technical guarantee. An actionable approach is to record missing rows, incorrect columns, missing fields, unavailable data, and items requiring human confirmation separately, state a verifiable scope of completion, and prioritize fixes by user loss. The 2026 return interview

Stable and Replaceable Layers of Engineering Assets

Dify’s return interview in December 2025 traced the evolution of its 2023 prompt/RAG tools into enterprise workflows, plugins, and coordination across multiple models. Model upgrades should not force users to rebuild every process. Plugins, retrieval components, and model interfaces can be replaceable, while sensitive business fields, approved steps, and existing assets need compatibility commitments. The guest’s description of being “production-ready” does not refer to one accuracy figure, nor mean zero failures. Concrete acceptance checks should cover regression of existing workflows, field structures, stopping at exceptions, human–AI review, upgrades, and rollbacks. Four or five hundred nodes, or thousands of workflows, are self-reported customer examples; scale does not establish that fully automated management has been achieved. For nonstandard collaboration between organizations, a workflow’s role is to express clearly who executes, who provides feedback, and where a human must be involved. When a person repeatedly generates and selects a satisfactory result, delivery responsibility still rests with that person. This and the early Dify notes from 2023 describe an evolution across stages; later capabilities must not be retroactively attributed to the initial version. Dify’s 2025 return interview

Addition: For natural-language-to-SQL, validate business meaning before production use

This section draws on the Builders account of Andy Pavlo’s MAD interview. It distinguishes the guest’s experience from the applications proposed here. It adds concrete checks for database tasks. One bank’s investment or accuracy is not a universal standard, and the interview’s forecasts of future traffic are not treated as established facts.

Map business terms to query constraints that people can review

An executable SQL statement only shows that the database accepted it. Whether its result answers the business question also depends on definitions and data scope. Before generation, establish the business terms, corresponding tables and columns, relationships, time conventions, access permissions and what counts as the correct result. A model or MCP interface having database access does not mean it knows the company’s business semantics or may read every column.

The following are proposed clarification and acceptance questions, rather than implementations supplied by the interview:

Check Clarify before generation Retain for acceptance
Business definition Does “active customer” mean a login, a transaction or a contract? An agreed definition and counterexamples
Tables and columns Which table and primary key apply? How should records be joined and deduplicated? Column mappings and known correct results
Data scope What are the time boundaries, time zone and permitted data scope? The data version, scope and authorization record
Result meaning Should the query return individual records, a count of people or a monetary amount? How are missing values interpreted? Human-reviewed examples and expected results

Record execution, result correctness and production validation separately

First validate meaning against internal business tasks with explicit expected results, then check whether it holds with real data and permissions. A run without errors, a matching result on one example and sustained usability in production represent different levels of acceptance. Keep failed questions, incorrect SQL, expected results and the regression examples used after a fix together. These records help distinguish failures in business definitions, column mappings, data scope and generation.

Pavlo warns that training data may cover public benchmarks, so benchmark scores cannot directly stand in for a particular company’s actual accuracy. This is a risk raised in the interview, not independent proof that a particular model’s evaluation was contaminated. Record test and production workloads separately as well. Passing in a test environment still requires checking production data scale, query behavior and actual business results; test success alone does not establish production acceptance.

Use this approach when business users ask questions in natural language, agents generate queries or analysis spans multiple tables. If business definitions are unsettled, first supply those definitions and examples of correct results. A model with a higher leaderboard score cannot resolve an unspecified business definition.

October 21, 2026 addition: persistent work does not require an always-on execution computer

This addition is based on Shensiquan’s Chinese account of Lee Robinson’s Stanford presentation. The original course, Grok Bot code and deployment have not been independently checked. Claims that hallucinations are essentially solved, automated review is usually safer or agents will soon work continuously for months are not adopted as verified conclusions.

Recover task state separately from the execution computer. The account describes keeping conversations, memory and routines on the server while starting the execution computer on demand and restoring or rebuilding it from snapshots. Patching, replacing or suspending that computer need not discard the task’s goal and progress. Firecracker and Temporal are named in the source. The transferable mechanism is a replaceable execution environment with reliable records of progress and results, rather than a requirement to use those particular technologies.

Recovery needs separate checks for where to resume and whether the previous external action already took effect. Durable workflows can help preserve progress, but a framework name alone does not guarantee that an email, payment or external write happens exactly once. When a result is uncertain, inspect external state and receipts before retrying. Isolation, the task loop and identity permissions also require separate verification.

Prioritize user interruptions and combine background events. The account gives direct changes to a user’s goal priority, while group messages and background work queue up and may be batched when they arrive together. Preserve each event’s source and handling result so batching does not lose a cancellation or changed instruction. Remaining quiet when there is no material progress differs from stopping execution. Notifications, requests for approval and messages already sent should have distinct records.

Keep cache prefixes stable while recognizing compression loss. Stable ordering of tool definitions and system prompts can reduce unnecessary prefix changes. Preparing a compressed summary while a long conversation’s cache is warm is also a cost-management idea. Cache hits still depend on the service, retention period and request content; not every miss has the same cause. Compression loses information, so retain original logs, essential constraints and retrievable files rather than treating a summary as a complete original record.

Source links and related public notes

October 23, 2026 Addition: Estimate Agent Work From Its Execution Model

Estimate delegated work from how the agent actually executes it, rather than copying a human working-day estimate. Swyx’s personal assessment of Opus 5.5 stresses that sustained execution and parallelism can change elapsed time. His example of two or three days versus two or three hours is not a universal productivity guarantee and comes without an independent benchmark.

Application in this knowledge base: ask the agent to identify subtasks, dependencies, parallel work and human handoffs before estimating completion. Update remaining time and its reasons when blockers or repairs appear. After completion, compare the forecast with elapsed time to learn which tasks this model and tool combination estimates well. A record of “initial estimate—latest estimate—actual time—reason for error” is an editorial suggestion, rather than a format specified by the source.

A short estimate does not replace authorization or remove time spent waiting for a person, service queue or unavailable tool. External commitments still depend on actual dependencies and resources. Link this to planning, isolated execution and independent review in the coding-agent article; estimation quality does not prove output correctness.

Source: https://x.com/swyx/status/2113283272130412684

Addition: Check logical isolation and shared-hardware risks separately

Separating agents’ accounts, files, processes and execution sandboxes does not establish that they have no shared underlying hardware. Guillermo Rauch’s account of a shared-host timing issue adds a different layer to isolation checks: when two actors share a machine, CPU-cache interference may be observable through their own execution timing. Such a side channel does not require directly handing one task’s files to another. A check that directories cannot access each other therefore cannot establish complete isolation.

This retains Rauch’s public account; the attack has not been independently reproduced here, and Vercel Sandbox has not been audited. He presents dedicated hardware per agent as addressing this class of shared risk, while acknowledging its economic cost. That must not be expanded into a claim that every attack is solved. Ask separately how logical access is isolated, whether machines and caches are shared, what mitigations and monitoring are used, and what residual risks remain. A vendor’s report that mitigations are deployed is different evidence from proof that a risk is eliminated.

Editorial application: select an execution arrangement according to task sensitivity and cost, and record the shared layers, known limits and incident owner during acceptance. Dedicated hardware still does not replace account permissions, code review or readback of external actions. Low-risk demonstrations need not copy the most expensive configuration. For related operational responsibilities, see Enterprise AI.

Source: Guillermo Rauch’s post. The acceptance checks above are editorial applications.