AI Agent 是被"逼"出来的：从一个 API 调用到复杂系统的完整成长路线图

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

快速摘要

如果你只想要一句话结论，那就是这句：不要一上来就给 AI 系统搭最完美的架构。AI agent 本身是一个不确定性系统，你在它之上再叠一层精致的编排，等于在不确定性上再乘一层不确定性，结果往往是更贵、更慢、更难调试。正确的路径是反过来走——从一个最小的 API 调用起步，只有当"当前这一步真的解决不了了"，才被逼着往上加一层能力：先是链式 workflow，再是对话式 agent，接着是工具、上下文隔离、子智能体、记忆系统、可观测性。每一层都不是设计出来的，而是问题倒逼出来的。 这篇文章我会把这条成长曲线上每一个"临界点"讲清楚：到底是什么信号出现的时候，你才真正需要升级到下一层。判断标准比架构本身重要得多。

我自己踩过的坑是：读到几篇写得极好的工程文章，觉得照着抄一遍系统就能变强，于是连夜升级架构、隔离上下文、加记忆——做完发现整个系统比原来还烂。后来才想明白，那些文章是"毕业设计的完整图纸"，而我当时连地基都还没打。

想看完整拆解，往下翻。下面每一节都对应成长路上的一个真实节点，我会把原理、判断信号、和具体怎么落地都摆出来，尽量做到图文并茂、新手也能跟上。

一、新手最容易踩的第一个坑：在不确定性上再叠一层不确定性

先说一个很反直觉的结论，也是我折腾了很久才认下来的：做 AI agent 和做传统软件，底层逻辑不一样，甚至有点相反。

写后端出身的人有一种根深蒂固的肌肉记忆——架构要先设计好。你做一个服务，先把分层、部署、模块边界都规划得整整齐齐，前期慢一点没关系，后面稳。这套思路在确定性系统里几乎不会错，因为每个模块的输入输出是可预期的，你搭的结构越完备,系统越稳。

但大模型不是确定性系统。同样一句话、同样一段上下文，它这次和下次的输出可能就不一样。这在学术上有个说法叫"非确定性"（non-deterministic），说人话就是：它的行为你没法百分之百复现。 你在这样一个本就飘忽的东西上面，再搭一套精密的多步编排，会发生什么？每一步的抖动都会往下游传导，第一步偏一点，第二步就偏更多，到第五步链路已经跑到不知道哪里去了。这就是"在不确定性上再叠一层不确定性"。

举个我自己干过的蠢事。我当时只是想把一段话压缩成一句摘要——这本来是一个 API 调用就能干完的活。但我脑子一热，直接给它套了一个"先规划、再执行"（plan-and-execute）的模式，觉得这样"更专业"。结果呢？

# 我原本需要的：
输入一段话 → 一次模型调用 → 输出一句摘要   （1 步）

# 我实际搭出来的：
输入一段话
  → 第 1 次调用：让模型规划"我应该分几步来总结"
  → 第 2 次调用：让模型按计划执行第一步
  → 第 3 次调用：执行第二步、合并
  → 输出摘要                                （3+ 步，token 翻几倍）

任务一点没变复杂，链路先变复杂了。token 花得更多，效果没更好，还多了两个可能出错的环节。不是 AI 不行，是我一开始就把路走复杂了。

我后来反复琢磨过，为什么传统软件那套"先设计后施工"的直觉，到 AI 这儿就失灵了。核心差别在于反馈的确定性。传统模块你写完就知道它对不对，输入 A 一定出 B，你的架构是建立在一块块"确定的砖"上的，砖越多、拼得越规整，楼越稳。而大模型这块砖，它本身的形状每次都在微微变化，你把十块这样的砖严丝合缝地砌起来，误差不是抵消，而是累加。更麻烦的是，传统 bug 你能一步步单步调试定位，AI 系统里一个"它今天没理解好我的意思"这种问题，你连断点都下不了。所以在你还没验证"模型到底能不能做成这件事"之前，任何精密架构都是在给一个未知数做华丽的包装。先证明可行，再谈优雅，这个顺序在 AI 系统里几乎是铁律。

所以这一整篇文章其实只讲一件事：AI agent 是怎么从一个小到不能再小的问题，一步一步被逼着长大的。 我不会给你一张终态架构图让你照抄，我要带你走一遍这条路上每一个岔路口——在什么信号出现的时候，你才该往上加东西。把这些判断节点想清楚了，你自然知道自己现在该站在哪一层，而不是盲目地一步到位。

二、成长的起点：先从一个 API 调用讲起

在拆解那些复杂概念之前，得先把最朴素的形态摆出来，不然后面所有的"升级"都失去了参照。

我自己做内容这块，其实很早就在用 AI 了，而且用得极其朴素。比如起标题，我就是把稿子丢进去，让它一口气生成十个候选，我挑一个顺眼的。再比如做配图，我让它生成一个视觉主体，剩下的排版我自己上手。

这类任务有一个共同特征：输入进去，一次调用，结果就出来了，中间不需要任何来回。 这就是 AI 应用最原始的细胞——一次 API 调用（API call）。

这里先给新手把词儿解释清楚。所谓 API 调用，你可以理解成"给模型发一条请求、拿一条回复"这么一个来回，就像你在对话框里打一句话、它回你一句，本质是同一件事，只不过是用代码发出去的。它是无状态的——这次调用不知道上次说过什么，也不会自己去查资料、用工具，就是纯粹的"一问一答"。

用户输入  ──►  模型  ──►  结果
         （一个来回，结束）

绝大多数人低估了这个最简单形态能覆盖的场景。分类、改写、摘要、润色、起标题、抽关键词、把一段中文翻成英文……这些活，一个 API 调用配上一个好一点的提示词，往往就够了。Anthropic 在他们那篇讲构建高效 agent 的工程文章里也反复强调过同一个意思：先找最简单的方案，只有在确实需要的时候才增加复杂度，很多应用其实根本不需要做成 agent。

我把这一层叫做"地基"。后面每加一层，都要问自己一句：这一层是真的被需要，还是我手痒想用点酷的？

三、第一条铁律：一个 API 调用能搞定的，别上 agent

顺着上面说。如果我为了"起个标题"这点事，专门搭一个 agent、挂一堆工具、做记忆、做规划——那就是给蚊子装火箭助推器。看着酷，完全没必要，而且贵。

所以成长路上的第一条原则简单到有点残酷：如果你的问题一个 API 调用能解决，就不要用 agent，更不要为了"用上 agent"而用 agent。

这话听起来是废话，但你去看真实项目，一大半的过度设计都栽在这儿。大家太想用新东西了。看到"agent"这个词很兴奋，看到"多智能体"更兴奋，恨不得手上每个需求都做成一个能自主决策的复杂系统。可 agent 是有代价的——它天生就比一次简单调用更慢、更贵。

这里有个业内被反复引用的数据可以帮你建立体感：一个自主 agent 消耗的 token 大约是一次普通对话调用的 4 倍左右，而多智能体系统更是能到单体 agent 的 10 到 15 倍。这不是 bug，是这类系统的固有特征——它会不停地循环、推理、自我复盘、来回调用工具，才做出一个决定。所以每多一层自主性，你的账单和延迟都在往上走。

我给自己立了一条自检习惯，每次想上 agent 之前先过一遍：

先别急着理解后两行，下面几节会一行一行讲透。你现在只要记住这一层的判断：能一步搞定的，坚决一步搞定。 把这条守住，你已经躲掉了新手期一大半的无用功。

四、多步骤 ≠ agent：确定性的长流程，交给 workflow

我的需求很快就升级了。做内容的人都懂，成品前面有一堆琐碎的体力活。就拿"把一段素材里啰嗦、重复、卡壳的地方处理掉"这件事来说，它显然不是一次调用能完成的了，它是一整条链路：

原始素材
  → 步骤 1：转成带时间戳的结构化文本
  → 步骤 2：逐段判断哪些地方需要处理
  → 步骤 3：生成一份处理方案
  → 步骤 4：按方案去操作，产出成品

看到"多步骤"，很多人的第一反应是：那我上 agent 吧。这就是成长路上第二个特别容易犯的错误。多步骤，不等于需要 agent。

关键要看这条链路有没有一个决定性的特征：中间过程需不需要人介入。 你把上面这条流程再读一遍会发现，它有一种非常自然的使用方式——用户上传素材，点一下"一键处理"，等着拿结果就行。输入是确定的，中间步骤是固定的，输出是一次性给到的，全程不需要用户在中间插嘴。

这种任务，本质上是确定性任务，哪怕它步骤很多、中间也夹着好几次模型调用，它依然只是一条"流程"，而不是一个需要自主决策的智能体。这种情况下，agent 反而是多余的、是负担。

这类活正确的落地方式是 workflow（工作流）——一种把步骤串成链条、按预定路径跑到底的结构。这里再给新手把 workflow 和 agent 的本质区别讲清楚，这也是 Anthropic 工程团队反复强调的一条分界线：

• workflow：由你写好的代码路径来编排模型和工具，走哪一步、下一步去哪，是你定死的，模型只负责在每个节点里出力。控制权在你手上。
• agent：由模型自己决定下一步用哪个工具、什么时候算做完，你只给目标和边界。控制权在模型手上。

用一句更形象的话：workflow 像是你指挥、模型跟着你的节奏走；agent 像是你雇了一个很聪明但有点混乱的实习生，让它自己去把事情办成——有时候办得漂亮，有时候用一种贵到吓人的方式办成。

落到工具上，做这种确定性长流程，市面上的可视化编排平台就完全够用了。比如 n8n 这种把节点拖来拖去连成图的自动化平台，或者 Dify 这种把 RAG、编排、发布都集成好的开源平台，链式结构一拉，几十步也能稳稳跑完，根本不需要对话、不需要多轮交互。

我把这条判断浓缩成一句可以贴在显示器上的话：

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

多步骤本身不是升级到 agent 的理由，"人要不要下场"才是。这一步想明白，你又能省掉一大坨过度设计。

我再举一个跟内容无关的通用例子，帮你把这条判断迁移到别的领域。假设你要做一个"客服工单自动分类归档"的系统：收到一封工单，先判断它属于退款、投诉还是 bug 报告，再抽取关键字段，再按类别写进不同的表，最后发一封确认回执。这一整套五六步，看着也"很多步"，但它同样是确定性的——输入是一封工单，路径是固定的分支逻辑，用户不需要在中间跟系统对话。这种就是教科书级的 workflow，你用一个带条件分支的编排图就能跑，模型只在"判断类别""抽字段"这两个节点里出力，其余都是你写死的代码路径。

# 确定性流程（workflow）——路径你说了算
收到工单
  ├─[模型判断类别]─► 退款  ─► 抽字段 ─► 写入退款表 ─► 回执
  │               └► 投诉  ─► 抽字段 ─► 写入投诉表 ─► 回执
  │               └► bug   ─► 抽字段 ─► 建 issue    ─► 回执
  └─ 全程无需用户中途介入

你看，哪怕这里也用到了模型、也有分支，它依然不是 agent，因为控制权始终在你手上，模型没有资格决定"下一步我要不要换个干法"。这就是 workflow 和 agent 最本质的分野。

五、那到底什么时候，才真正需要一个对话式 agent？

前面两层一直在"劝退"，这一节我们正式跨过那道门槛。我用自己踩的一个坑来回答。

我当时做了一个"一键生成特效"的功能，天真地以为跟"一键处理素材"一样，点个按钮就能拿到我满意的动画效果。现实立刻给了我一巴掌：它几乎不可能一次就到位。有时候风格不对，有时候节奏不对，有时候我就想微调一个小细节。

问题就出在这类任务的性质上——它不是对错题，它常常是审美题。 要么是模型能力暂时够不着，要么是"好不好看"这件事本身没有标准答案，需要人下场去指点、去教它、去反复试反复改。

如果这个时候你还死磕"按钮"这条路，会发生什么？你会被迫不停加按钮：一键重做、一键换风格、一键改配色、一键换模板、一键再生成……每冒出一种新需求，前端就多一个按钮，最后整个产品变成一个飞机驾驶舱，密密麻麻全是钮，用户看着就晕。

到这一步，一个通用入口的价值才真正浮现出来——与其为每一种可能的操作都做一个按钮，不如给用户一个能用自然语言表达任意意图的对话框。这，才是狭义上"对话式 agent"真正被需要的时刻。

我把触发条件收敛成两个信号，满足任意一个，才考虑上对话式 agent：

反过来说，如果你的任务既有确定的输入、又不需要人中途介入、选项也就那么固定几种——那它到现在为止都还轮不到 agent，老老实实用前面的 workflow 或者干脆一个 API 调用。

Anthropic 后来把 agent 的定义收敛得非常干脆：让大模型在一个循环里自主地使用工具。 注意"自主"和"循环"这两个词——正是它们带来了灵活性，也正是它们带来了成本和不可预测。所以你要非常清楚自己是为了什么才付这个代价。

我想再强调一遍那个反向的判断，因为它救过我好几次。有一次我又想给一个"批量给图片配文案"的功能上 agent，理由是"感觉挺复杂的"。但我逼自己过了一遍那两个信号：人需要中途下场吗？——不需要，用户就想一键拿到一批文案。选项会爆炸吗？——不会，就"配文案"这一件事。两个都不满足，那它就还是个 workflow，我硬上 agent 只会让它更慢更贵更难调。"感觉复杂"从来不是理由，"信号出现"才是。 你越能忍住不上 agent，你的系统往往越健康——这话听着别扭，但做久了你会认同。

六、技术选型：别被"最强框架"迷了眼，先把东西跑起来

确定要上 agent 之后，我又马上犯了一个特别典型的错误——一开始就想选一个最强、最完整、号称能 cover 一切情况的框架，那种轻量的方案我压根看不上。

我脑子里有个幻觉：我这问题这么复杂，链路这么长，那我必须上最硬核的后端编排框架才配得上。后来才发现这是个概念错误。链长，不等于你必须用复杂的调度系统；很复杂，不等于后端很重。

我当时把两种"长链"搞混了，这个区分特别重要，值得单独掰开：

第一种长链，是 workflow 的长链。 你点一下按钮，它从头跑到尾，十步二十步一口气连续执行，中间不停。这种情况下你确实要认真考虑任务分发、失败重试、队列调度、并发恢复这些重活儿，因为它真的会在后端"横着跑到底"，中途出任何岔子都得自己扛。

第二种长链，是对话式 agent 的长链。 它不是这么跑的。它是一种"可以被人切开"的长链——每跑完一步、或者跑几步就停一下，跟用户确认一下再往下走。整条流程看着很长，但每一次真正连续执行的片段其实很短。

workflow 长链：  ●─►●─►●─►●─►●─►●─►●   （一口气跑完，中间不停）

agent   长链：   ●─►●──停──●─►●──停──●   （随时可被人切开、确认）

这个区别的意义在于：对话式 agent 的长链，很多时候根本不需要一上来就搭一个能连续跑二十步、还要扛住各种异常的重型调度系统。 因为它本来就走走停停。

所以我最后选了一个看起来平平无奇的方案——一个集成度高、上手快的 SDK（我用的是 AI SDK 这一类）。有人觉得它不够无敌、不够万能，但它有一个压倒性的优点：能先把东西跑起来。 只要它能完成最基础的对话、最基础的工具调用，我就能在真实任务的迭代里去验证和修正。顺带一提，这类 SDK 现在也早就把工具调用循环、多步执行、甚至配套的调试面板都做进去了，起步阶段完全够使。

这里还要补一句更隐蔽的坑：重型框架会诱导你瞎设计。 当你选了一个很能打的编排框架（比如那种基于图的调度框架），它会天然地勾着你——你还没跑起来任何东西，就开始画节点：这事该拆成哪几个 step、哪个节点负责什么、数据怎么在节点间流转……听起来特别专业，但问题是，你连"这个问题模型到底能不能解决"都还不知道。 这就是闭门造车，路修得再宽，方向错了全白费。

这里其实藏着两重不确定性：第一，这个问题本身模型能不能搞定；第二，你这套架构会不会反过来干扰它。两个都没验证，你的精致设计就是空中楼阁。

所以我的建议很实在：即便你选了复杂框架（这不是错），也请先用它最简单的用法把问题跑一遍，先把 baseline（基准线）跑出来。 知道任务的底线在哪之后，再决定要不要加节点、要不要上更复杂的编排。

一句话收尾这一节：别被后端迷了双眼，"先跑起来"比"一步到位做到完美"重要得多。 这也是我在词元二号站上写技术复盘时，反复提醒自己的一条。

七、系统提示词：从最简单的一句话开始，再一点点加约束

AI SDK 跑起来之后，下一关自然是设计系统提示词（system prompt，就是你给模型定的那套"你是谁、你该怎么干活"的底层说明）。我又踩了一个超级典型的坑——我想把提示词也一步写到最强。

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

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

这背后其实是 Anthropic 在上下文工程那篇文章里点破的一个概念：提示词要写在"合适的高度"（the right altitude）。 两个极端都是坑：一个极端是把复杂、脆弱的逻辑全硬编码进提示词里，想精确操控模型的每一步，结果系统又脆又难维护；另一个极端是写得太空太泛，模型无所适从。你要找的是中间那个"金发姑娘区间"。

我自己摸出来的实操节奏是这样的，反过来走，效果特别好：

1. 第一版故意写得极简、几乎不加限制，就看模型自己会怎么做。
2. 观察它的输出，哪里不满意，就针对性地加一条约束——想让输出更格式化，就加格式要求；想让某一部分多思考，就单独点出来；
3. 想让它风格稳定，就给它几个例子，让它照着例子往外产出（这招在业内叫 few-shot，白话就是"给范例，让它模仿"）；
4. 只要这个 agent 能 follow 你的指令，你就一条一条往上加，它能照着做。

# 别这么开局（一上来就是一本说明书）：
"你是资深设计师，必须遵循以下 27 条规则：1.… 2.… 3.…（省略 24 条）"
        → 又慢又贵，还不一定更好

# 这么开局（先简后繁，按需加约束）：
v1: "你是一个视觉设计师，给我一个方案。"        → 看它怎么做
v2: + "输出请分成 配色 / 版式 / 氛围 三块。"      → 加一条格式约束
v3: + （附 2 个我喜欢的范例）                     → 用例子校准审美

说实话，能走到"它能稳定 follow 你逐条加的指令"这一步，系统提示词这一关就已经过了。

我后来也想明白了，为什么照抄别人的"神级提示词"往往会翻车。别人那套提示词，是为他们那个具体项目、具体工具集、具体模型长出来的，里面每一条约束背后，都对应着他们踩过的某一个坑。你把它整段搬过来，等于把别人的一身伤疤连同别人的体质一起穿到自己身上——你没有他们那些坑，那些约束对你就是纯粹的负担，白白消耗 token，还可能把模型往你根本不需要的方向硬掰。提示词这东西没法"移植"，只能"生长"：从你自己的最简版开始，被你自己的问题一条条喂大。这跟前面讲架构的道理其实是同一个——**别人的终态，不是你的起点。**但紧接着你会撞上一个更本质的问题——很多时候它做不好，根本不是提示词写得不够好，而是这个任务需要的能力，它压根就没有。 这就引出了下一层。

八、加工具：能力的缺失，靠改提示词是补不出来的

接着上一节。我让 AI 做动效设计的时候，我心里真正期待的是：它能参考一下当下网上流行的设计风格。但问题是——它根本拿不到这些数据。 它的知识停在训练那一刻，它没长眼睛去看今天的世界。

这种时候，你把提示词改出花来都没用。这不是"写法"的问题，是"能力"的缺失。 分清这两者，是这一层最关键的判断力。

所以正确的动作不是继续折腾提示词，而是加工具（tools）。 给新手解释一下：所谓给 agent"加工具"，就是给它一些能真正对外界产生动作的函数——比如一个搜索工具让它能去联网查资料，一个代码执行工具让它能验证自己写的代码到底跑不跑得通。模型自己决定什么时候调、调哪个、传什么参数。

判断逻辑非常直接：

• 我希望它能参考外部信息 → 它就必须会搜索；
• 我希望它写出来的代码是可用的 → 它就必须能验证（能跑一遍看对不对）；
• 我希望它能读我给的文件 → 它就必须能读文件。

每一个"我希望它能……"，背后对应的往往就是"给它一个工具"。

当你把三四个工具加上去之后，会有一个非常明确的体感——它开始像一个 agent 了。 它会自己想清楚这一步该用哪个工具，甚至开始把工具串起来用：先搜索、再根据搜到的东西写代码、再跑一遍验证、不对就再改。这种"工具之间产生了 (1+1>2) 的效果"，业内叫 涌现（emergence）。

单个工具能力：  搜索  ┃  写代码  ┃  跑验证
                 ↓
串起来用之后：  搜索最新风格 → 参照着写实现 → 跑一遍验证 → 不对再改
                 ↑ 这套自发的组合，就是"涌现"

加工具这件事，还有一个新手很容易忽略的细节：工具好不好用，一半功夫在工具的"说明书"上。 你给模型挂一个搜索工具，光有函数还不够，你得用一句话把"这个工具是干嘛的、什么时候该用、要传什么参数"讲清楚，就像你给新来的同事交代一件事。说明写得含糊，模型就会该用的时候不用、不该用的时候乱调。我的经验是，工具描述要像写给一个聪明但没有背景知识的人看——直接、具体、给边界。必要的时候，给一两个"什么样的输入是对的"示例，比你写一长段文字管用得多。

顺便提一个你迟早会遇到的名词：MCP（模型上下文协议）。你可以先粗浅地理解成"一套让 agent 统一接入各种外部工具的标准接口"——有了它，你想给 agent 接一个新数据源、新服务，不用每次都从头造轮子，按这套协议接上就行。现阶段你不用深究，只要知道"工具生态正在被标准化"这件事就够了，等你工具多到管理不过来的那天，自然会回来找它。

要特别注意：到这个阶段，我们其实什么复杂架构都没做。 没有引入规划器，没有搞多智能体，系统提示词也还是最基础的版本。仅仅是"基础对话 + 几个好用的工具"，就已经能让系统显著变聪明。

那段时间做 agent 的体验，说实话，爽爆了。你每加一个工具，它就肉眼可见地聪明一点，之前做不了的能做了，之前很勉强的现在能跑通了。于是你会忍不住继续加、继续加、继续加……

——然后，你就会一头撞进下一个非常诡异的阶段。

九、涌现之后的失控：注意力被稀释的那个临界点

加工具加得正开心的时候，系统会毫无预兆地进入一个诡异状态。不是偶尔失败，而是性能持续性地变差：成功率开始下降，准确率忽高忽低，有时候它甚至开始"听不懂人话"。而且你能明显感觉到——它不是不会做，而是越做越乱。

我第一反应是"模型不行了"。错。问题不在模型，在于你的上下文（context）开始失控了。

这里有个我想单独说说的心理陷阱：加工具是会上瘾的。前面提到那种"每加一个工具它就聪明一点"的正反馈，会让你产生一种错觉——只要继续加，它就会一直变强。于是你不停地加、加、加，直到某一天它开始崩。这个转折点特别隐蔽，因为它不是"啪"地一下坏掉，而是温水煮青蛙式的、持续性的退化：今天成功率掉了两个点，你以为是波动；明天它答非所问，你以为是运气不好；后天它把一个简单任务做得乱七八糟，你才惊觉不对。等你回过神，系统已经在一个你说不清哪里出问题的状态里泡了好几天了。所以我给自己定了条规矩：每加一个工具，都要重新验证一遍整体表现，而不是只盯着新工具本身好不好使。 加法要克制，验证要跟上。

这里得先把"上下文"这个词讲透，它是后面所有内容的地基。上下文，就是模型在生成这一次回答时，眼前能看到的所有信息的总和——你的系统提示词、每个工具的说明书、用户这轮的输入、之前的历史对话、贴进来的代码、图片……全都算。模型就是盯着这一整坨东西来"思考"的。

而这里有一个残酷的物理事实：模型的注意力是有限的，它是一种会被稀释的稀缺资源。 Anthropic 把这件事说得很直白——大模型有一个有限的"注意力预算"（attention budget）。工具一多，每个工具背后都挂着一大段说明；任务一复杂，输入本身也更长；再叠上历史对话、代码、图片……所有信息一股脑塞进去，模型的注意力被平均地摊薄了，反而谁都没看清。

这在业内是个被反复验证的现象，有人叫它"迷失在中间"（lost in the middle）——信息越长，中间那部分越容易被模型忽略；也有人叫"上下文腐烂"（context rot）——输入 token 越堆越多，性能不升反降。名字不重要，你要记住的是那个体感：不是加得越多越好，塞太多、太散，模型会被淹死。

上下文塞得太满时，注意力被稀释：

[系统提示][工具A说明][工具B说明][工具C说明][工具D说明]
[历史对话很长很长很长][贴进来的一大段代码][几张图]
[用户这轮真正想问的一句话]  ← 最关键的，反而被淹没在最中间

到这一刻——也只有到这一刻——我们才真正需要请出那两篇工程文章里的第一篇：上下文工程（context engineering）。之前我失败，不是文章不对，是我那时候还没走到需要它的阶段。

十、上下文工程：本质就一件事——只让模型看到它该看的

上下文工程听着玄，Anthropic 把它拆得很朴素：它是在做某一类任务时，让模型只看到它需要看到的那部分信息，其余的别往它眼前堆。用他们的原话去意会就是——在有限的注意力预算下，找出"信噪比最高、能最大概率产出你想要结果"的那一小撮 token。

还是拿我那个内容 agent 举例