黄益贺横跨 2024-04 至 2026-05 对 Agent 这个概念的演化判断 + 实战。从最早"Multi-Agent 难在 Workflow 设计"到 2026 自己做出多 Agent 编排产品 newtype OS 的全过程认知沉淀。
何时打开:
- 你在设计 Agent 系统但分不清 Workflow / Agent / Agentic Workflow
- 听到"通用 Agent" / "Manus 类产品",不知道值不值得跟进
- 用 Claude Code Sub-agents 觉得"好像不够",想知道真正的多 Agent 编排长啥样
- 想做 Agent 产品但不知道交付率怎么提
0. 概念地图
graph TD
A["Workflow<br/>空间结构 · 静态<br/>'做什么 / 按啥顺序'"] --> C["Agentic Workflow<br/>骨架 Workflow + 关键节点 Agent"]
B["Agent<br/>逻辑结构 · 动态<br/>'此时此刻该怎么办'"] --> C
C --> D["Multi-Agent 编排<br/>多个 Agent 协作<br/>(Chief / Deputy / 各角色 Sub-agent)"]
D --> E["Agent Native 协议<br/>专为 Agent 设计的 HTTP<br/>(预测 2026 后半年)"]
核心区分(2025-09 帖 1761):
| Workflow | Agent | |
|---|---|---|
| 本质 | 定义任务及任务间的依赖关系 | 感知环境 + 自主决策 + 执行动作 |
| 形态 | 流程图 / 蓝图(静态) | 时间展开的一系列动作(动态) |
| 核心 | 依赖关系 | 决策与执行 |
| 侧重点 | "做什么 / 按啥顺序做" | "此时此刻该怎么办" |
| 抽象层次 | 高(业务流程) | 低(执行智能) |
两者不是替代关系,是相辅相成:
- 一项工作 = 空间结构(Workflow)+ 逻辑结构(Agent)
- 一个复杂 Workflow 可能由多个 Agent 协作完成
- 把 Agent 作为 Workflow 节点 → Agentic Workflow
1. Multi-Agent 的核心命门:Workflow 设计(2024-04 帖 69)
老黄最早的判断(开 newtype 第二个月就说的):
"搭建 Multi-Agent System 在技术上一点都不难。难的是你得想清楚,你想让 Agent 怎么做。"
类比: Agent 就像一个文笔棒的实习生。把他招进来扔一堆资料说"10 分钟写完一篇文章",他肯定懵逼。所以你必须 站在系统的角度拆解任务 → 变成一套 Workflow → 映射到 Agent 上。
核心结论: Agent 的价值在于 Workflow。而 Workflow 怎么设计,要求你既懂 AI 又懂业务。
Why 这是行业 90% 项目失败的根因:
- 多数团队卡在"训模型 / 调 Prompt",不在 Workflow 设计上花心思
- 没有 Workflow,Agent 就是个能聊天的玩具,没法持续产出
- 业务理解才是 Multi-Agent 的真护城河,Prompt 工程是浅层
何时用:
- 启动 Agent 项目前,先画 Workflow 流程图,把每一步用人话写清楚
- 卡在"Agent 效果差"时,反问"我的 Workflow 拆得够细吗?哪个节点最模糊?"
2. Agentic Workflow:演进路径(2025-09 帖 1761)
演进顺序:
- 最初: 简单 / 固定的任务用 Workflow 完全自动化(纯流程图)
- 遇到复杂任务: 流程中某些节点包含大量不确定性、需要自然语言理解 / 与外部环境动态交互
- 引入 Agent 填充复杂节点 → 这就是 Agentic Workflow
形象比喻:
Workflow: [步骤1] → [步骤2] → [步骤3] → [步骤4] → 结果
↓
这一步太模糊
↓
Agentic Workflow: [步骤1] → [步骤2] → [Agent 自主决策] → [步骤4] → 结果
Why 这是 Agent 落地的正确姿势:
- 全 Workflow 太僵硬,处理不了复杂场景
- 全 Agent 不可控,交付率低(见 §5)
- Agentic Workflow = 绝大多数节点确定性,关键节点让 Agent 自主 = 兼顾可控性 + 灵活性
何时用: 设计 Agent 产品时,默认从纯 Workflow 起步,只在确实需要"理解 + 决策"的节点插入 Agent,不要一开始就上"通用 Agent"。
3. Agent Native 协议:MCP 之后的预测(2025-04 帖 1061)
老黄 2025-04 的预测:
现阶段的 Agent 产品(Computer Use / Browser Use)都是让模型去适应人类的生产环境。因为电脑、浏览器是给人类用的。AI 用起来不是不可以,但 效率一定低,成本也一定高(Token 花费、处理时间)。再强的团队都解决不了。
所以最终一定会出现一套 Agent Native 的东西,可能是协议(专属于 Agent 的 HTTP)。人类看不懂也不需要看懂,就是专为 Agent 获取信息和交互而设计。
预测的时间点: MCP 成熟之后,可能 2025 年底或 2026 年。
论证逻辑链:
- MCP 是以模型为核心的协议,帮模型进化为 Agent
- 大量 Agent 出现 → 才会有 Agent Native 协议的必要性
- 现在的一切都是权宜之计
2025-10 老黄的反思(帖 2535): newtype OS 自己就 彻底 CLI 化了。不是 To Human,而是 To Agent。命令行 + 结构化输出 = 当下最接近 Agent Native 的接口形态。
Why 这个判断对产品方向决定性:
- 投资 Browser Use / Computer Use 类产品 = 在为 Agent 适配 Human-only 接口而努力 = 长期会被绕过
- 投资 Agent Native 接口(CLI / API / Protocol)= 当 Agent Native 协议出现时直接受益
何时用:
- 看到"AI Operator / Computer Use Agent"这类产品时,问"它的接口是 Human-first 还是 Agent-first?是不是中间形态?"
- 设计自己产品的接口时,默认上 CLI / 结构化 API,不上 GUI(除非用户需要)
4. CLI Agent 的逻辑(2025-07 帖 1461)
Why Claude / Gemini 都推出 CLI AI 编程工具(老黄解读):
命令行 Agent = 庞大的现有工具生态 + 经典的 Unix 组合哲学 + 现代的 AI 调度能力(如 ReAct)
指向的未来:
命令行 Agent + 成熟的 MCP 生态 = 通用 Agent 骨架
四阶段执行循环:
- 感知: Agent 通过 MCP 全面了解你的意图和当前系统状态
- 思考: LLM 大脑进行推理
- 行动: Agent 通过 CLI 接口执行一系列命令
- 循环验证: Agent 再次通过 MCP 检查文件系统,确认任务完成,向用户报告
Why CLI 比 GUI 强 10 倍(对 Agent 而言):
- Unix 工具几十年的组合性(管道、stdin/stdout)对 Agent 友好,GUI 对 Agent 不友好
- CLI 输出是文本/JSON,Agent 直接消化;GUI 输出是像素,Agent 要先 OCR
- CLI 操作可以批处理 / 并发 / 失败重试;GUI 需要点击模拟,慢且脆
何时用:
- 评估 AI 工具时,有 CLI 版的优先选(为未来 Agent 化做准备)
- 设计自己工具的接口时,先做 CLI,GUI 是 nice-to-have
5. 提高 Agent 交付率:3 法则(2026-01 帖 2208)
老黄给 Agent 产品的判断框架:
| 法则 | 内容 | 本质 |
|---|---|---|
| 1 | 任务明确 | 减法:边界要紧 |
| 2 | 场景封闭 | 减法:不能让 Agent 在无限开放世界乱跑 |
| 3 | 结果可验证 | 闭环:必须有自动化方式验证 Agent 输出对不对 |
核心洞察:
通用 Agent 的陷阱是,试图在一个无限开放的世界里解决模糊问题。然而,目前 AI 的能力还是 概率性的。要得到确定性的产品交付,就 必须人为限制搜索空间。
对第 3 点的强调:
如果你想做一个成功的 Agent,请先问:我有什么自动化手段能验证 AI 生成的东西是对的?如果没有,你的产品很难走出 Demo 阶段。
Why 这 3 法则决定产品生死:
- 没有第 1 + 第 2 → Agent 跑偏,用户不知道它在干嘛
- 没有第 3 → 用户每次都要人肉验证,使用成本比不用还高,产品没人用
- Demo 时三个都不需要,生产时三个都需要 → 这是为啥很多 Demo 产品死在上线后
何时用:
- 启动 Agent 项目前,先回答这 3 个问题。回答不了 = 项目还不能开干
- 看到火爆的 Agent Demo 时,反问"它在生产时这 3 条满足吗?"(大多数答案是否)
6. Manus 不被看好的原因(2025-03 帖 941)
老黄 2025-03 的当面 diss(Manus 发布时市场狂热):
如果你过去半年高频用 Claude / Cursor / Deep Research,看到这种拆解需求 / 搜集信息 / 调用工具的做法,不会感到震惊,只是微微一笑。
Manus 的命门: 通用 Agent 是巨头(OpenAI / Anthropic / Google)高度关注的战场。
"有点东西"不足以让你在三家的碾压下活下来。所有基于模型的修修补补,都将被模型能力升级而覆盖掉。没模型,只能昙花一现。
老黄的预测: 国内媒体会持续吹("中国 AI"这个选题需要 DeepSeek 代表模型 + Manus 代表 Agent),Manus 趁机多拿点钱看变数。
Why 这个判断重要:
- 任何在"通用 Agent" / "通用 Coding Agent" 赛道竞争的产品,都在跟模型厂商的下一代模型赛跑
- 模型每升一代,通用 Agent 上一代的"包装"就会被原生能力吃掉(典型例子:GPT-4 自带 Browser → 替代了很多 Browser Use 类产品)
何时用:
- 听到任何"通用 Agent" / "用 Agent 干掉所有 SaaS"的叙事,先问"模型 v+1 出来后这个产品还存在吗?"
- 做产品方向选择时,避开模型公司未来一定会做的方向(通用 Coding / 通用 Browser / 通用 Research)
7. Claude Code Sub-agents 不算"真正的多 Agent 编排"(2026-01 帖 2266)
老黄的辨析:
Claude Code 的 Sub-agents 并不算行业所期待的"多 Agent 编排",只能算是一种 多代理机制。
真正的多 Agent 编排 5 大特征:
| # | 特征 | 内容 |
|---|---|---|
| 1 | 层次化与嵌套编排 | 支持 meta-orchestrator 管理子 orchestrator(团队中的团队),允许复杂委托链 + 辩论/审核机制 |
| 2 | 多模型 / 跨提供商支持 | 不同 Agent 用不同模型(Opus 规划 / Flash 执行 / Grok 搜索),优化成本/性能 |
| 3 | 共享状态与高级协调 | 持久记忆 / 冲突解决 / 动态路由 / 循环迭代 / 错误恢复,由外部代码或框架管理 |
| 4 | 真正并行与扩展性 | 支持数十甚至数百 Agent 并发,适用于长运行 / 大规模任务(全栈应用重构 / 企业自动化) |
| 5 | 开源 / 可编程灵活性 | 开发者用代码定义 workflow,而不是依赖单一 LLM 的"自然语言委托" |
Claude Code Sub-agents 的实际地位:
"内部任务路由 + 轻量委托,而非独立的多 Agent 框架。入门级,只适合简单场景。"
何时用:
- 评估 Claude Code 用法时,认清 Sub-agents 是"轻量委托"而不是"完整编排"
- 想要做严肃多 Agent 产品时,看这 5 条做产品需求清单
- 选型 Multi-Agent 框架时,5 条不满足 3 个以上就是玩具
8. newtype Profile 的多 Agent 编排实战(2026-01 帖 2276)
架构:
Chief(主 Agent / 编排者)
↓ 拆解 + 分派
Deputy(副手 / 执行官)
↓ 再分派
Researcher / Editor / Fact-checker / ... (各特定角色 Agent)
关键行为:
- 分工明确: Chief 只编排和对话,不亲自干活
- 并行执行: 多个 Researcher 任务同时跑
- 透明可控: 右上角任务列表实时显示后台进度
- 人机协作: Chief 在后台任务运行时,跟用户讨论细节,确认需求
- 结构化输出: 最终汇总为表格、列表等易读格式
Agent 模型配置(老黄的实战):
| Agent | 用哪个模型 | 理由 |
|---|---|---|
| Chief | Claude(Opus 4.6) | 规划 + 逻辑能力强 |
| Deputy | Claude | 同上 |
| Researcher | Gemini | 大上下文窗口 |
| 其他执行类 | Gemini Flash / Claude Sonnet | 看成本/速度需求 |
Why 这套架构验证了 §7 的 5 大特征:
- 层次化(Chief → Deputy → 角色 Agent)✓
- 多模型(Claude + Gemini 混合)✓
- 并行执行 ✓
- 持久记忆(通过 newtype-profile.json + .config 文件夹)✓
- 代码定义(SKILL.md + profile JSON,不是自然语言指挥)✓
何时用:
- 设计自己的 Multi-Agent 产品时,直接抄这套 Chief / Deputy / Specialist 三层架构
- 解释"什么叫真正多 Agent 编排"时,把这个图给对方看
9. AI Agent = New Content(2026-01 帖 2274)
老黄的判断:
旧内容只是信息的快照。新内容是一个封装了知识 / 逻辑 / 工具的实体。它是活的。
用户对它的操作是 "提问" / "调用" / "协作"。
Agent 重新定义了信息的"交付形态"和"消费方式"。它使内容不再仅仅是信息的载体,而是服务的载体。
对 Content Creator 的启发:
这对 Content Creator 来说是个 掀桌子级的机会。
逻辑推导:
- 过去做内容 = 写文章 / 拍视频 → 用户看完就结束了
- 现在做内容 = 封装成 Agent / Skill / 插件 → 用户每次需要时直接调用,产生持续价值
- 内容创作者的护城河从"内容质量"扩展到"内容 → 服务的转化能力"
实例: 老黄把自己上百篇视频脚本喂给 Gemini,提炼"个人操作系统三张表"(概念表 / 关系表 / 流程表) → 然后这些抽象出来的东西变成 Skill / Profile → AI 调用 newtype-os 时就是在调用老黄过去 3 年的内容沉淀。
何时用:
- 你是 Content Creator,想"超越纯内容"时,问"我的内容能不能封装成可调用的 Agent?"
- 你做 SaaS 产品,想加内容护城河时,问"我的产品里的 SOP / Knowledge 能不能开放成 Skill 给用户的 Agent 调用?"
10. Agent 个人生产系统三层(2026-02 帖 2462)
架构:
┌─────────────────────────────────────┐
│ 1. 知识库层(Knowledge Layer) │
│ - 外部资料(历史数据 / 行业报告) │
│ - 个人资料(过往笔记 / 视频脚本) │
├─────────────────────────────────────┤
│ 2. 技能层(Skill Layer) │
│ - Skills 封装的经验 SOP │
│ - Sub-agents 配置 │
│ - 多 Agent 编排(newtype Profile)│
├─────────────────────────────────────┤
│ 3. 实时信息层(Realtime Layer) │
│ - 新闻 / 新视频 / 长文章 │
│ - 通过 OpenClaw / Kimi Claw 定时 │
└─────────────────────────────────────┘
老黄自己的进度(2026-02 自评):
- 知识库层: 已搞定(2024 年多个视频在边搭建边分享)
- 技能层: 进行中(2025 多个 Skills 发布,2026 多 Agent 编排做出来)
- 实时信息层: 之前没好办法,2026 春节用 OpenClaw / Kimi Claw 自动化搞定
Why 三层而不是一层:
- 知识 ≠ 技能 ≠ 实时数据,生命周期不同,刷新频率不同,管理方式不同
- 混在一起会导致 AI 系统失控(老知识混新事件,Skill 触发条件混乱)
- 三层独立 → 可以独立升级、独立 debug
何时用:
- 自己搭 AI 系统时,先按这 3 层划分文件夹,按层独立设计 SOP
- 评估别人的 AI 系统时,问"这 3 层都有吗?哪层最弱?"
11. AI 时代三层框架(2026-02 帖 2360)
老黄给整个 AI 行业的导航图:
第一层:技术栈(从下到上)
- 底层: 模型能力(Pre-training → Reasoning → Long Horizon)
- 中层: 基础设施(Framework → Harness → Memory System)
- 上层: 应用场景(Coding → SRE → Research → Vertical)
第二层:价值链(从供给到需求)
- 供给侧: AI 创造新能力(比如 Long Horizon Agent)
- 传导层: 新能力重构 Workflow(比如 GitHub 从仓库变成派单系统)
- 需求侧: 新 Workflow 创造新需求(比如"用 AI 写代码"成为常态)
第三层:竞争格局(从通用到专用)
- 通用层: 模型厂商(OpenAI / Anthropic)争夺入口
- 基础设施层: 独立玩家(LangChain / MemOS)提供可迁移的能力
- 应用层: 垂直公司(Factory / Rogo)在特定场景建立壁垒
对不同角色的战略意义
创业者:
| 做哪层 | 战略 |
|---|---|
| 底层(模型/引擎/记忆系统) | 追求通用性,建立技术壁垒,目标成为基础设施 |
| 中层(Harness/工具集) | 追求最佳实践,快速迭代,目标成为事实标准 |
| 上层(垂直应用) | 追求场景化,积累记忆资产,目标建立领域护城河 |
投资人:
| 看哪层 | 关注什么 |
|---|---|
| 底层 | 技术壁垒,是否有"反包"其他技术的可能 |
| 中层 | 工程能力,是否能把模型能力转化为可用产品 |
| 上层 | 场景深度,是否能在垂直领域建立无法复制的记忆资产 |
个人:
| 维度 | 切换 |
|---|---|
| 认知 | 从"需求侧"切换到"供给侧",从"我需要什么"切换到"我能创造什么" |
| 能力 | Coding 可能成为新的"识字",不一定要成为程序员,但要理解代码逻辑 |
| 资产 | 你与 AI 的协作记忆是你的个人资产,要有意识地管理和积累 |
何时用:
- 评估任何 AI 产品/项目时,先定位它在哪层 → 估算它的天花板和竞争者
- 自己做决策时,问"我在第二层(价值链)的哪一侧?需求侧还是供给侧?"
12. Page Rank → Agent Rank(2025-05 帖 1317)
预测: 搜索引擎进化成问答引擎之后,整个生态的流量分配规则都会重新改写。
对工具网站的影响:
| 过去 | 未来 |
|---|---|
| 查 IP 地址 / JPG 转 PNG 等工具网站靠 Google 推荐 + 广告变现 | 用户点击行为变少 → 工具网站靠 Page Rank 的红利消失 |
| 用户输入关键词,选择最高排名 | AI 直接给答案,工具调用变成 Agent 内部行为 |
核心机会:
有些工具的能力会被模型内化,但依旧 有大量不值得内化、调用一个小型/微型 Agent 就能满足。这有可能是 不起眼的大机会。
Why 这个判断有价值:
- 不需要做"颠覆性的 AI 应用",做"被 Agent 频繁调用的小工具" 也是巨大机会
- 评估自己产品的标准从"用户多不多"转向"被 Agent 调用频次高不高"
- 一旦产品被 Anthropic / OpenAI 的 Agent 习惯性调用,就有了护城河
何时用:
- 做小工具产品时,设计"易被 Agent 调用"的接口(REST / MCP server)而不是只有 Web UI
- 评估老工具网站时,问"它的能力 GPT-5 会不会内化?如果内化,它怎么自救?"
13. 通用 Agent 应聚焦"轻松"而非"更强"(2025-09 帖 1772)
老黄的产品方向洞察:
OpenAI《How People Use ChatGPT》报告验证了我一个感觉: AI 除了让人更强之外,还有一个非常容易被忽视但又非常刚需的点 — 让人更轻松。
典型场景:
- 很多认知不错的用户希望 AI 帮忙先写个大概(写作),或者回答问题 / 搜集信息
- 不是他们做不到,是 想轻松点,在 AI 完成 70-80% 基础上再接手
ChatGPT / 御三家能满足一大半,剩下大量细分 / 垂直需求 → 一个个 AI 小产品来填补。
老黄的产品方向公式:
一个单点突破的洞察 + Claude Code SDK 作为 Agent 引擎 + 现代美观的 UI = 胜算可能比那些要做 OS / 平台的项目更高
Why 这个反直觉:
- 行业关注"AI Agent 能干多酷的事"(让人更强)
- 真实用户需求是"AI 能不能让我少干点活"(让人更轻松)
- "轻松"维度的细分市场被严重低估
何时用:
- 想做 AI 产品但不知道做什么时,从"用户已经能做但嫌烦的事"切入,而不是"用户做不到的事"
- 看到"我们的 AI 让效率提高 N 倍"叙事时,反问"用户是想要更快还是想更轻松?"
14. Context > Compute(2026-01 帖 2248)
核心心法:
Context > Compute
做中间层的架构师。
谁拥有最精准的 Prompt 和最完善的 Context,谁就拥有最高的"智力转化率"。
意思:
- 模型能力(Compute)在快速涨,但用户实际拿到的输出质量不只取决于模型,更取决于喂进去的 Context 质量
- 给 GPT-3 喂精心准备的 Context,可能比给 GPT-5 喂模糊 Prompt 效果更好
- 中间层架构师 = 设计 Context 流水线的人 = 比"调模型"更值钱的角色
Why 这影响个人技能投资方向:
- 学"prompt engineering" → 已经被 Prompt House / 工具替代大半
- 学"Context Engineering"(怎么组装、清洗、压缩、检索 Context 给模型)→ 长期增值
- 学"做基础设施"(知识库 / Memory System / Retrieval)→ 中间层永远需要
何时用:
- 学习计划做选择时,选 Context Engineering 相关而不是单纯 Prompt 工程
- 看产品时,关注它的 Context 管理能力(检索质量 / 记忆策略),不只看模型选型
15. Agent 犯错的正确反应(2026-03 帖 2579)
心法:
当 Agent 犯错时,你的第一反应不应该是"再试一次",而是想一想:环境里缺了什么能力。
意思:
- Agent 错了 → 不是模型笨,而是 它的工具箱 / Context / 验证机制有缺口
- "再试一次"是 stochastic gambling,改不了根因
- 找出缺什么 → 补 Skill / MCP / Memory → 下次自然对
Why 这是 Agent 产品 debug 的正确姿势:
- 大多数人的本能是"换 Prompt 重跑",这是 surface fix
- 真正的修复是 架构层面:加新工具 / 加新数据源 / 加新验证步骤
- 这跟程序员 debug 一样:错误一旦能复现,根因一定能定位,而不是"赌下一次能跑过"
何时用:
- Agent 错了,先 stop。问"它需要什么我没给"(工具?数据?验证?)
- 评估 Agent 产品时,看它出错后的处理是 retry 还是补能力
16. 反 pattern:Agent 设计这些坑别踩
| ❌ | ✅ |
|---|---|
| 上来就做"通用 Agent" | 先做单点 Agentic Workflow,验证 §5 三法则 |
| 全 Workflow 或全 Agent | Agentic Workflow:骨架 Workflow + 关键节点 Agent |
| 模型选最贵的 | 不同 Agent 不同模型,Researcher 用大上下文模型,Chief 用强推理模型 |
| Agent 错了就 retry | 想"环境里缺了什么能力",补 Skill / MCP / Memory |
| 跟巨头抢通用赛道 | 避开模型公司未来一定会做的方向(Manus 的命门) |
| 设计 Agent 接口只做 GUI | 默认 CLI,GUI 是 nice-to-have |
| Claude Code Sub-agents 当多 Agent 框架 | 它是"轻量委托",严肃多 Agent 用 OpenCode / LangGraph / 自建 |
| 把所有内容堆给 Agent | 三层分(知识库 / 技能 / 实时信息),独立管理 |
| 强调"AI 让用户更强" | 同等关注"AI 让用户更轻松"(被低估的维度) |
| 卷 Prompt Engineering | 学 Context Engineering(中间层架构师) |
引用与延伸
主要引用: newtype 知识星球精华帖:69, 941, 1061, 1317, 1461, 1761, 1772, 1812, 1902, 1912, 2208, 2248, 2266, 2274, 2276, 2360, 2462, 2535, 2579
配套 wiki:
- newtype 心法 · 超级个体方法论 — 个人价值观 / 心法底座
- newtype · Vibe Coding 独立产品实战 — 老黄实战的产品演进(newtype Profile / CLI / OS)
- (TODO)newtype · MCP 协议与生态实战 — MCP 协议深入
- (TODO)newtype · RAG 实战与知识库演化 — RAG + 知识库(三层架构第 1 层)
- (TODO)newtype · Prompt / Context Engineering 实战 — Prompt 进阶用法 + Context Engineering
跨系列相关:
- 王凯 SOP
multi-agent-browser-matrix-v1.1.md(Phase 2 处理)— 多 Agent 浏览器矩阵架构,跟本 wiki §8 是平行实现 - 王凯
Claude-Code 工作流方法论综述.md(Phase 2)— Claude Code 内部 Sub-agents 使用,跟本 wiki §7 的辨析强相关
History
- 2026-05-16 v1.0 创建 — 从 newtype 全帖索引萃取 wiki #3(Phase 1.1 · 3/12)。核心覆盖 Agent / Multi-Agent / Workflow / Agentic Workflow / Agent Native / CLI Agent / 提高交付率 3 法则 / Manus 命门 / Claude Code Sub-agents 局限 / newtype Profile 架构 / Agent = New Content / 三层框架。来源会话:Session 2 wiki 切片。