AI 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 大基础模式

Sequential(顺序流水线)
Parallel(并行汇总)
Loop(循环迭代直到达标)
Router(基于内容路由)
Fork-Join(分发-汇总)
Map-Reduce(大数据分块处理)
Reflexion(自反思自纠正)
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 条曲线

与王凯 Agent 工程实操 L1-L5 类似但用 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 补建):

深思圈 / AI Agent 公司案例库 —— Cursor 训练即产品 + Anthropic 权限护城河 + Agent 4 大类型 + 11x 暴雷教训
深思圈 / AI B2B 垂直行业(8 大赛道独角兽案例) —— 8 大垂直 Agent 赛道独角兽案例(销售/客服/招聘/法律/医疗/保险/HR/金融)
深思圈 / 头部 AI 公司动作(OpenAI/Anthropic/Google/Apple/Perplexity) —— 头部公司 Agent 战略对比

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 视角	看垂直深度 + 记忆资产 + 是否被模型升级吃掉

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

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

11. 引用清单

主要原始 author wiki:

newtype · Agent 架构与多 Agent 编排 —— 老黄 2024-04→2026-05 帖子级判断 / 5 大特征 / Chief-Deputy-Specialist / Agent Native 预测 / Agent 是新内容
AI Agent 技术架构演进 2025(深度研究报告) —— 研究报告 / 4 大编排 + Google ADK 8 模式 / MemoryOS 3 层 / 6 框架对比 / Morgan Stanley 案例
AWS Agent 系列讲座 2025(4 篇汇编) —— AWS 4 篇(汪其香 / 王晓妍 / 常高伟 ANP / idoubi)
Agent 研究论文 3 篇精读(2024-2025) —— 3 篇论文(CAMEL Scaling Laws / More Agents Is All You Need / ChatQA)
AI Agent 市场投资趋势 2025(数据报告) —— 2026-01 Agent 市场投资趋势($870 亿 / 191 独角兽 / 25× 收入倍数)
王凯 Agent 工程实操 —— 王凯 272 帖 / Agent 分级 L1-L5 / MCP 实战清单 / 自动化任务体系 / 200 美金 Polymarket 实验
王凯多 Agent 浏览器矩阵架构(v1.1 实操指南) —— 多浏览器矩阵 v1.1 / 身份 × 工种 / cdp-proxy / hub 协调
Lenny's Newsletter / 2026 AI 时代组织运营三人谈(Anthropic + OpenAI) —— Embiricos Codex / Cat Wu Cloud Code / Compaction / Mixed-Initiative / AGI 瓶颈
深思圈作者全集入口 —— 深思圈 69 篇"Agent" / VC 视角 / a16z 估值

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

学到的设计原则:

写测试让 agent 不跑偏(无人监督下,测试是唯一对错信号)
任务结构化让多 agent 并行不撞车
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-05-19:增补 §2026-05-19 节(Anthropic 工程团队第一方视角)。加 Anthropic 5 个 building block 和 4 类 harness、Carlini 16 Claude 实证、Multi-Agent Research 架构。新增 cross-link 到 Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集) / AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) / LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战)。
2026-05-18:Topic-dimension wiki 首发。从 9 份 author wiki 综合改写。显式标注 4 条分歧:Agent 物理 vs 逻辑 vs 采样 / 创业方向 vs 模型公司必吃 / 编排中心结构 / Agent 是不是新内容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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