从一次 API 调用到工业级智能体：AI Agent 架构的成长路线图与踩坑复盘

本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

做 AI Agent 最容易犯的错，不是架构太简单，而是一开始就太复杂。一个能用一次 API 调用解决的问题，别上 Agent；一个步骤固定、中间不需要人插手的长流程，用 workflow（比如 n8n、Dify 这类链式编排）就够了，也别上 Agent；只有当"人必须参与判断"或者"功能多到没法为每个需求单独做一个按钮"时，你才真正需要一个对话式的 Agent。真正的架构不是一步到位设计出来的，而是被一个个具体问题逼着长大的：先跑通最小版本 → 提示词从最简单写起 → 遇到能力缺口才加工具 → 上下文塞爆了才做隔离 → 需要传递不可改动的长内容才引入记忆系统 → 系统复杂到没法调试了才把运行全过程存成 trace。顺序永远是"走到这一步、发现不用不行了，再用"。把 Anthropic 那两篇关于上下文工程和长任务的文章当成毕业设计图纸可以，但别拿着图纸在第一天就照着施工——那样你连第一根梁都立不起来。

这套判断标准，我是拿自己做视频 AI Agent 一路踩坑换来的。想看完整拆解、每一步到底卡在哪、又该怎么破，往下翻。

一、先把话说清楚：AI Agent 为什么不能照搬传统软件的设计习惯

我一开始是带着一个特别"工程师"的直觉进场的：既然本质上还是在做系统设计，那我把架构提前规划得越完备，系统不就越稳吗？这个想法放在传统后端里一点毛病没有。你做一个部署模块，把容器编排、服务拆分、异常兜底提前想清楚，最多就是前期慢一点，不会出什么大乱子，因为传统软件是确定性的——同样的输入，进同样的函数，出同样的结果。

但大模型这套东西不吃这一套。我后来才想明白一个挺反直觉的点：一个基于大模型的 Agent 本身就是非确定性系统（同样一句话问它，两次的回答、走的路径都可能不一样）。你在一个非确定性系统上面，再精心地搭一层复杂架构，等于是在不确定性上面又叠了一层不确定性。两层不确定性一叠加，系统的行为你根本预测不了，出了问题你也定位不了。

举个我自己干过的蠢事。我最初只是想把一段话压缩成一句话，这么点事，我却直接给它套了个 plan-and-execute（先规划、再执行）的模式。本来一次 API 调用就能收工，被我拆成了"先生成计划、再逐步执行"。任务本身没变复杂，可链路先复杂了。结果不是模型不行，是我一上来就把路走窄走绕了。

所以辛梓煜想先立一个基调：AI Agent 的成长，跟盖楼不一样。盖楼是图纸先画全再动工；Agent 更像养一棵树——你得先让它活下来，再根据它长歪的地方一根一根去修枝。整篇文章其实只讲一件事：一个小到不能再小的问题，是怎么被一步步逼着，长成一套复杂的工业级系统的；以及这条路上，到底是哪个具体的节点、哪个具体的痛点，才真正需要你给它加上对应的那层架构。

二、第一性原则：一个 API 调用能解决的，就别上 Agent

先讲讲我的真实起点。我做内容其实很早就在用 AI 了，而且用得特别朴素。比如起标题，我就是把稿子丢进去，让它一口气给我十个候选，我挑一个顺眼的；再比如做封面，我让它生成一个视觉主体，剩下的文字我自己排。这类活儿，说白了就是一次 API 调用（把输入丢给模型、拿一次回复，一来一回就结束）的事。

如果为了这么点事，我专门搭一个 Agent，配上一堆工具、给它做记忆、做多轮规划——那就是给蚊子装火箭助推器。看着酷，纯属没必要。

这里其实对应了 Anthropic 在那篇《Building effective agents》里反复强调的一个心法：先找最简单能跑通的方案，只有在确实需要的时候才往上加复杂度。他们把这类最基础的东西叫"增强版大模型"（augmented LLM）——就是一个大模型，配上检索、工具、记忆这几样最朴素的能力。对相当多的应用来说，把单次调用配上检索和几个示例，就已经够用了。

所以第一条原则非常简单，也非常残酷：

如果你的问题一个 API 调用能解决，不要用 Agent。不要为了用 Agent 而用 Agent。

我把不同复杂度的任务，和它们真正该用的方案，整理成一张表，方便对号入座：

这张表后面几节会一格一格地展开。你会发现，Agent 的成长路线，本质就是这张表从上往下走一遍的过程。

2.1 先问一句：这事真的需要"智能体"吗

我后来养成了一个习惯，每次冒出"要不要做成 Agent"的念头时，先逼自己回答一个问题：**这件事，真的需要模型自己拿主意吗？**如果答案是"不需要，步骤我心里清清楚楚"，那它就不该是 Agent，顶多是个把大模型当成其中一环的普通程序。很多人跳过了这个自问，纯粹是被"用上智能体显得高级"这种心理推着走的——包括当初的我。

多提一句成本的账。业内一个大致的经验值是：一个 Agent 消耗的 token，大概是普通聊天调用的四倍上下；如果你还上了多智能体，那可能就是十几倍。这意味着你每往"更智能"的方向迈一步，账单都会跟着往上跳一档。所以"能不能不上 Agent"不是抠门，是对系统的负责。

2.2 从"增强版大模型"这块积木讲起

再往下拆，其实所有 Agent 系统最底层的那块积木，就是前面说的"增强版大模型"：一个裸模型，加上三样东西——检索（能从一堆资料里找出相关的那部分）、工具（能调用外部能力）、记忆（能记住该记的东西）。现在的模型已经能主动地用这几样：自己生成搜索词、自己挑合适的工具、自己判断哪些信息值得留下。

关键在于，这三样不是一次性全上，而是缺什么补什么。你会在后面几节看到：工具是在第七节"遇到能力缺口"时才补的，记忆是在第十节"要传不可改的长内容"时才补的。一开始，你手里可能只有一个裸模型加一次检索，这就够你把第一版跑起来了。积木要一块一块往上垒，别一上来就想搭成城堡。

三、多步骤 ≠ Agent：先搞懂 Workflow 和 Agent 的分界线

后来我有了新需求。剪片子的时候我发现一件特别琐碎的事：录的时候难免有语气词、有些地方说得磕巴。剪辑其实就是在花时间给自己擦屁股。我自然就想，能不能让 AI 把这种重复啰嗦的地方自动剪掉。

问题到这儿就升级了。这已经不是一次 API 调用能搞定的了，它是一整条链路：先把视频转成带时间戳的字幕 → 根据字幕判断哪些片段要剪 → 生成一份剪辑方案 → 回头去驱动音视频轨道。这是个不折不扣的多步骤问题。

但请记住一句话：**多步骤 ≠ Agent。**这里藏着第二个特别容易踩的坑。很多人一看到"多步骤"，条件反射就是"那我上 Agent"。不一定。

因为这条链路有个决定性的特征：中间过程不需要用户介入。你可以想象它最自然的用法——用户上传视频，点一下"一键剪辑"，拿到剪好的成品。输入是确定的，中间步骤是固定的，输出是一次性交付的。这种情况下 Agent 反而是多余的。它本质上是个确定性任务，哪怕它很长、步骤很多、中间穿插了好几次 AI 调用，它也依然只是一条流程。

这时候正确的选择是 workflow（工作流）那种链式结构。用可视化的工作流工具就完全够了——比如 n8n（一个靠拖拽节点连线来搭自动化流程的平台，拖几个节点就能把一串 API 串起来），比如 Dify（面向大模型应用的编排平台）。它们最适合的场景就是这种：步骤可预测、能提前把控制流写死、不需要对话、不需要多轮、也不用让用户中途插嘴。

这正好对得上 Anthropic 对两者下的定义。它把 workflow 和 Agent 做了一个架构上的关键区分：

• Workflow：大模型和工具，是被预先写好的代码路径编排起来的。控制流在你手里，路是你铺的。
• Agent：大模型自己决定下一步用哪个工具、怎么走、什么时候算做完。目标和护栏是你定的，但每一个分支不是你写死的。

后来 Anthropic 干脆把 Agent 提炼成一句更简单的话：大模型在一个循环里自主地使用工具。

给你一个判断指标，屡试不爽：

如果用户不需要在中间反复参与，那你大概率不需要对话式 Agent。

用一张流程图对比一下这两条路，差别一眼就出来了：

flowchart TD
    A[用户提交任务] --> B{中间需要人反复介入吗?}
    B -->|不需要| C[Workflow 链式编排]
    C --> C1[步骤1 固定]
    C1 --> C2[步骤2 固定]
    C2 --> C3[步骤3 固定]
    C3 --> D[一次性交付结果]
    B -->|需要| E[对话式 Agent]
    E --> E1[模型自主决定下一步]
    E1 --> E2{要不要调工具?}
    E2 -->|要| E3[调用工具后回到判断]
    E3 --> E1
    E2 -->|够了| F[阶段性交付 等人确认]
    F --> E1

左边这条路，是从头跑到尾、中间不停；右边这条路，是可以被人切开的——这个区别，第五节还会专门再挖一层。

3.1 别小看"确定性流程"这条路

我想替 workflow 这条路多说两句，因为它经常被低估。工程师群体里有种审美倾向：觉得"写死的流程"很土，"能自己思考的智能体"才酷。可真放到生产环境里，恰恰是那种"土"的确定性流程，扛住了绝大多数的活儿。原因很简单——它可预测、好排查。一条链式流程出了问题，你能顺着"输入 → 某个节点 → 输出"一路走下去，像在一间灯火通明的屋子里找东西。而一个放飞自我的 Agent 出了问题，你面对的是一片会自己重新排列的森林，日志里全是"嗯，这个好像不太对"之类的模型自言自语，定位一个 bug 能把你熬到天亮。

举个通用化的例子。假设你要做一个"把一批产品图统一加水印、压缩、再改名归档"的活儿。这里面每一步都固定：读图 → 加水印 → 压缩 → 按规则重命名 → 存进对应目录。哪怕中间某一步你想让模型帮忙判断一下"这张图属于哪个分类"，它也依然是一条确定的流水线——你完全可以用 workflow 把它串起来，一键跑完。要是给这么个活儿配一个对话式 Agent，让它每张图都"思考"一番该怎么处理，那纯属自找麻烦：更慢、更贵、还更不稳。

一句话收尾这一节：**判断该不该上 Agent，看的不是"步骤多不多"，而是"路要不要模型自己临场决定"。**步骤再多，只要路是提前铺好的，它就还是 workflow。

四、真正需要对话式 Agent 的两个信号

那到底什么时候，才轮到对话式 Agent 上场？我用自己踩过的一个坑来回答。

当时我做了个功能，叫"一键生成特效"，本来想复制"一键剪辑"的爽感：点一下按钮，它就吐给我一套满意的动画效果。现实很快给了我一巴掌——它大概率不会一次就生成到我满意。有时候风格不对，有时候节奏不对，有时候我就想微调一个小细节。

这类任务的性质，和"一键剪辑"根本不一样。剪辑是道对错题，语气词剪没剪掉，一目了然。可特效设计常常是道审美题：没有唯一正确答案，甚至有时候是模型能力本身够不着，需要人去指导它、教它、陪它反复试、反复改。

如果这时候你还死磕"按钮"这条路，会发生什么？你会被迫不停加按钮：一键重做、一键改风格、一键换配色、一键套模板、一键再来一张……每冒出一种新诉求，你就得新增一个按键。加到最后，你的产品会长成一个飞机驾驶舱——密密麻麻全是按钮，用户看着就晕，你自己也维护不动。

到这一步，你才天然地需要一个通用入口——一个能用自然语言表达任意意图的地方，也就是对话。所以，你真正需要狭义上那种"对话式 Agent"的场景，基本就两个信号：

4.1 信号一：流程里人必须参与

不管是被动的（模型能力还够不到，需要人来兜底、来纠偏），还是主动的（这事儿本身依赖人的偏好和审美），只要"人必须在回路里"，对话就有了存在的意义。

4.2 信号二：功能选项多到前端指数级膨胀

当你发现自己没法、或者不想为每一种功能都单独做一个前端入口的时候，一个统一的对话入口，就是那个能收敛复杂度的解法。

这两个信号，只要中一个，Agent 才算真的"该上"了。辛梓煜的经验是：在没中这两条之前，任何"上 Agent 会更高级"的冲动，都值得压一压。

五、框架选型：链长 ≠ 后端重，先别被"重型架构"迷了眼

确定要上 Agent 之后，我又立刻犯了个特别典型的错：一开始就想挑一个最强、最完整、号称能 cover 一切情况的框架。那些看起来简单的方案我一概看不上。

脑子里的幻觉是这样的：我这个问题很复杂 → 所以我需要一条很长很长的链 → 所以我必须上最硬核的后端编排框架。

后来我才发现，这里其实混淆了两个概念。**链长，并不等于你必须用复杂的调度系统。**我把两种"长链"搞混了：

• Workflow 的长链：你点一下按钮，它从头跑到尾，十步二十步连续执行，中间不停。这种链你当然要认真考虑任务分发、失败重试、队列调度、并发恢复——因为它真的会在后端一口气横着跑到底。
• 对话式 Agent 的长链：它是一种可以被人切开的长链。它可以每跑完一步停一下，或者跑几步停一下，跟用户确认、交互，再继续。整体看它还是一条长流程，但每一次真正连续执行的片段，其实可以很短。

想明白这层，你就会发现：很多时候你根本不需要一上来就搭一个"能连续跑 20 步、还得扛住各种异常"的重型调度系统。

所以我最后选了一个看起来平平无奇的方案——AI SDK（一套 TypeScript 的工具库，主打把大模型的流式输出、工具调用这些能力，用很少的代码接进 Web 应用里）。它集成度高、上手快。有人觉得它不够"万能"，但它有个巨大的优点：能让你先把东西跑起来。

这里顺手把当下几种常见选择的定位摆一摆，帮你少走弯路：

一个业内挺有共识的做法是：前端用 AI SDK 做流式交互，后端如果确实需要重编排，再叠 LangGraph 这类框架——组合使用，而不是一上来就把最重的那套全端上。

5.1 复杂架构还会"诱导你瞎设计"

选重型框架还有个隐藏的坑：它会引诱你闭门造车。当你手里握着一个很唬人的编排框架，你会忍不住在还没跑通任何东西之前，就开始画节点：这事该拆成哪几个 step、哪个节点负责什么、数据怎么在节点之间流转……听起来特别专业，问题是——你连"这个问题模型到底能不能解决"都还不知道。

这地方其实有两重不确定性叠在一起：第一，这个问题模型本身能不能搞定；第二，你这套架构会不会反过来干扰它。所以辛梓煜的建议很朴素：

就算你选了复杂框架，也请先用它最简单的用法跑一遍，把这个问题的 baseline（基准线，也就是"什么都不加、模型裸跑能到什么水平"）跑出来。知道任务的底线在哪之后，再决定要不要加节点、要不要上更复杂的编排。

别被后端迷了双眼。"先跑起来"永远比"一步到位做到完美"更重要。

5.2 "先跑起来"到底是一种什么心态

我得强调，"先跑起来"不是让你糊弄、不是让你写烂代码。它是一种把不确定性尽早暴露出来的策略。你越早让系统真实地跑一次，就越早知道：这个问题模型到底能不能解决、瓶颈卡在哪、你脑子里那套架构设想到底是帮忙还是添乱。这些答案，一行架构图都给不了你，只有真实运行才能给。

我自己的教训是：那段最"高效"的时期，恰恰是我什么架构都没画、就抱着一个最小方案闷头跑的时候。反而是我坐下来认真画节点图、设计数据流转的那几天，产出的东西最后大半被推翻了——因为我画的全是猜的。等我真跑了一遍，才发现好几个"我以为很难、专门为它设计了复杂节点"的环节，模型裸着就能过；而好几个"我以为很简单、没当回事"的地方，反而是真正的深坑。

所以在框架选型这一关，辛梓煜的建议就一句：**先用最轻的方式跑通一个能用的版本，让真实的运行结果来告诉你下一步该往哪儿加复杂度。**架构不是设计出来的，是被真实反馈一点点校准出来的。

六、系统提示词：从最小可用版本开始，一句一句往上加

把 AI SDK 跑起来之后，下一关自然就是写系统提示词（system prompt，也就是你给模型定的"角色设定 + 行为规则"那段话）。我又光速踩了个典型的坑：我想把 prompt 也一步到位写到最强。

我当时到处搜成熟项目的提示词，那种被传来传去、号称"效果炸裂"的还嫌不够，我还专门去翻某些知名项目泄露出来的系统提示词，心想别人写得这么狠，我照着抄总不会差吧。结果两秒钟翻车：第一，效果没更好；第二，token 消耗直接爆炸。

举个例子，我只是想让它帮我出个视觉设计方案。我不给复杂 prompt，就一句"你是个视觉设计师，给我一个方案"，它反而能给我一个挺快、挺能用的结果。可当我把那一大坨专业提示词一股脑砸进去，它开始拆步骤、规划流程、一板一眼地执行——最后更慢，还不一定更好。

这件事，Anthropic 在《Effective context engineering for AI agents》里讲得很到位。它提出提示词要写在一个**"合适的高度"**（right altitude），是两个极端之间的黄金区：

• 一个极端：把复杂又脆的 if-else 逻辑硬编码进提示词，想精确控制每一个行为。结果就是又脆又难维护。
• 另一个极端：写得太笼统、太高层，或者默认模型跟你共享了一堆它其实并不知道的背景。

正确的姿势是先在最好的模型上跑一个最小提示词，看它怎么表现，然后盯着它失败的地方，再有针对性地补清晰的指令和示例。

这跟我自己摸出来的手感完全一致，我的做法是：

第 1 版 prompt：几乎不加限制，就给个角色，让它自由发挥，看它会怎么做
      ↓ 观察它在哪儿掉链子
第 2 版：针对具体的失败，补一条约束（比如"输出要按这个格式"）
      ↓ 再观察
第 3 版：想让某部分多想一点，就补一句思考引导
      ↓
第 N 版：给几个高质量示例，让它照着示例的调性往外输出

关于示例，还有个反直觉的点：别把你能想到的所有边界情况都塞进 prompt。堆一长串规则，不如精选几个有代表性的典型示例——对模型来说，一个好例子胜过千言万语。只要这个 Agent 能跟着你的指令走，你一句一句往上加，它都能照做，那系统提示词这一关，其实就算过了。

七、它做不好，往往不是提示词的锅，而是能力缺口——该加工具了

过了提示词这关，你会撞上一个很现实的问题：很多时候它做不好，根本不是提示词写得不够好，而是这个任务需要的能力它压根就没有。

还是拿动效设计举例。我期待它能参考一下网上正在流行的一些设计风格，可问题是——它拿不到这些数据。它的知识是训练时截止的那一刻定格的，它没长眼睛去看今天的网页。这种时候你把提示词改出花来都没用，这不是"写法"问题，是"能力"缺失。

所以正确的动作不是继续折腾系统提示词，而是加工具（tool，也就是让模型能调用的外部函数或接口，比如联网搜索、执行代码）：

• 我希望它能参考网上的信息 → 它就必须会搜索。
• 我希望它写的代码是能跑的 → 它就必须能验证（比如把代码跑一遍、看结果对不对）。

当你把三四个工具加上去之后，会有一个很明确的体感：它开始像一个 Agent 了。它会自己想清楚该用哪个工具，甚至开始把工具串起来用——搜完资料顺手就去写代码、写完代码顺手就去验证。这就是所谓的"涌现"：工具和工具之间出现了 1 + 1 > 2 的效果。

值得留意的是，走到这一步，我们其实还没有做任何复杂架构，没有引入规划、没有搞多智能体，系统提示词也还是最基础的版本。就靠"裸模型 + 几个好用的工具"，能力就已经上了一个大台阶。

举个"工具串起来"的具体画面。假设我给动效 Agent 配了三个工具：一个搜索工具、一个写代码工具、一个跑代码验证的工具。当我说"帮我做一个当下比较流行的加载动画"时，它自己会串成这样一条链：

[思考] 我不知道现在流行什么加载动画，先搜一下
   → 调用「搜索工具」，拿到几种当前常见的加载动画风格
[思考] 有素材了，选一个骨架清晰的方案来实现
   → 调用「写代码工具」，生成动画代码
[思考] 光生成不算数，得确认它真能跑
   → 调用「验证工具」，把代码跑一遍
[发现] 报了个错，某个属性写错了
   → 回到「写代码工具」，改掉，再验证
[通过] 交付

注意，这条链不是我写死的——我没告诉它"第一步搜、第二步写、第三步验证"，是它自己根据当前情况一步步决定的。这就是我说的"像个 Agent 了"的那种手感。

Anthropic 那篇文章也专门提醒过工具设计的坑：工具集不是越多越好。最常见的翻车方式之一，就是工具太多、功能重叠、边界模糊。一个朴素的检验标准——**如果连人类工程师都说不清某个场景到底该用哪个工具，那就别指望 AI 能分得清。**工具要少而精，每个都自成一体、职责清晰、返回的信息还得省 token。输入参数也要写得明白无歧义，别让模型去猜你这个参数到底想要什么。

再补一个新手常踩的坑：加工具的时候忍不住把每个工具的说明写得又臭又长，恨不得把所有边界情况都写进去。结果这些说明本身就把上下文撑爆了——这正好是下一节要讲的东西。工具的说明，也要遵循"少而准"的原则。

八、上下文失控：注意力预算与"上下文腐烂"

加工具那段时间，做 Agent 的体验只能用"爽"来形容。你每加一个工具，它就明显聪明一点，之前做不了的能做了，之前很勉强的现在居然能跑通了。你会忍不住继续加、继续加、继续加。

然后你会进入一个非常诡异的阶段。不是偶尔失败，而是这个 Agent 的表现持续性地变差：成功率开始下滑，准确率忽高忽低，有时候连人话都开始听不懂。而且你能明显感觉到——它不是不会做，是越做越乱。

这地方不是模型退化了，是你的**上下文（context，也就是每次喂给模型的那一整段信息：系统提示词 + 工具说明 + 历史对话 + 各种中间产物）开始失控了。**工具一多，每个工具背后都拖着一大段说明；任务复杂了，输入本身也更长；再加上历史对话、代码、图片各种信息一股脑塞进去——太多、太散，模型的注意力被平均地稀释掉了。

Anthropic 把这个现象讲得很透。它们借了一个研究里的概念叫**"上下文腐烂"（context rot）：随着上下文里 token 数量的增加，模型从里面准确回忆信息的能力反而会下降**。不同模型衰减的快慢不一样，但这个趋势在所有模型上都存在。原因和 Transformer 架构有关——每个 token 都要和其余每个 token 建立关联，n 个 token 就有 n² 对关系，上下文越长，注意力就被摊得越薄。

所以正确的心智模型是：**把上下文当成一种有限资源，而且是边际收益递减的资源。**模型和人一样有"注意力预算"，每多塞一个 token，就从这个预算里扣掉一点。

到这一步，我们才真正需要那篇文章的核心——上下文工程（context engineering）。它本质上只干一件事：

在做某一类任务的时候，只让模型看到它真正需要看到的东西。

用 Anthropic 的原话精神来概括，就是：找到那个最小的、信噪比最高的 token 集合，让它最大化地提升你想要的结果出现的概率。注意，"最小"不等于"最短"——该给的背景还得给足，关键是别掺进无关的噪音。

8.1 上下文预算，到底被谁吃掉了

抽象的话讲完，来看点具体的。你可以把每一次喂给模型的上下文，想象成一个有限的"预算盘子"，盘子里堆的东西大致是这么几类：

你会发现，真正把预算吃光的，往往不是任务本身，而是这些"周边"。同样一个任务，一个把周边收拾得干干净净的上下文，和一个塞满了历史垃圾和冗余说明的上下文，模型的表现能差出一大截。

8.2 一个最省力的第一刀：清掉用过的工具结果

如果你不知道从哪儿开始给上下文"瘦身"，有一个几乎零风险的起手式：**把已经用过、深埋在历史里的工具返回结果清掉。**道理很直白——一个工具在很早以前被调用过、结果也用完了，模型为什么还需要反复看到那一大坨原始返回？这类内容清掉，基本不会丢关键信息，却能省下可观的预算。Anthropic 把这类做法归到"压缩"（compaction）这个大思路下：当对话快撑到上下文上限时，把内容做一次高保真的总结，再用这份总结开一个新的上下文窗口继续跑，保留架构决策、没解决的 bug、关键实现细节，丢掉那些冗余的工具输出和废话。用户那头感觉不到断裂，模型这头却轻装上阵了。

九、上下文隔离：设计和写代码，是两类需要不同"食材"的任务

上下文工程听起来抽象，落到我这个视频 Agent 上，就特别具体。当我想设计某种视频效果时，这件事其实内含了两类性质完全不同的任务：

9.1 两类任务，两种胃口

• 第一类是"设计"。它关心用户的意图、视觉风格、版式元素、整体氛围。它需要大量开放、可发散的信息，然后对这些信息做分析和归纳。
• 第二类是"写代码"，把设计好的东西落地实现。它关心的是明确的接口、清晰的结构、输出的格式和正确性。它需要的是尽量少、尽量精确的信息。

这俩的"胃口"是相反的：一个要广、要杂、要能联想；一个要窄、要准、要没干扰。

9.2 混在一起会怎样

如果你把这两件事塞进同一个上下文里，任务小的时候可能还能凑合跑。可任务一复杂，设计那堆发散信息会开始扰乱代码生成的准确性，代码那些琐碎细节又会拖慢设计的判断——两个任务开始互相污染上下文，系统得花大量算力去把它俩理清楚。

只有当"不同任务明显需要不一样的上下文"这件事成立时，上下文隔离才真正有了意义。这时候你才该开始考虑:要不要有一个顶层的规划者(planner)，它掌握全局信息，负责调度;下面挂几个执行者(executor / subagent，只负责某个专项的子智能体)。设计的 subagent 只碰设计相关的内容，代码的 subagent 只碰代码的内容，而且这俩通过规划者的控制，各自只看到自己那一小撮必要信息。

这正是 Anthropic 讲的"子智能