AI Agent 开发完全图景：从 0 到商业产品

行业里「agent」被用得很滥。但 Anthropic 和 OpenAI 的官方定义出奇一致：判据只有一条——是谁在控制流程。

Anthropic 在《Building effective agents》里给出了被引用最多的区分[1]：workflow 是「LLM 和工具被预定义的代码路径编排」的系统——流程是你写死的，模型只在每个节点上干活；agent 是「LLM 动态指挥自己的流程和工具使用、自主掌控任务完成方式」的系统——模型自己决定下一步做什么。OpenAI 的官方指南给出了同样的判据，并明确把简单 chatbot、单轮调用、情感分类器排除在 agent 之外：不用 LLM 控制工作流的应用不是 agent[9]。

这个区分不是咬文嚼字，它直接决定你的系统的可预测性、成本和错误模式。Workflow 的每一步都在你掌控中，便宜、可测、好调试；agent 能处理「事先无法预测要走几步」的开放式任务，但代价是更高的成本和错误累积（compounding errors）的风险——这正是 agent 难做的核心工程原因[1]。

五种 workflow 模式：agent 之前的全部武器

在真正需要 agent 之前，绝大多数需求可以用五种可组合的 workflow 模式覆盖[1]。这五个名字值得记住——它们是 agent 圈讨论架构时的基础词汇：

注意 orchestrator-workers 已经站在 workflow 和 agent 的边界上：拆解是动态的，但「拆解→委派→汇总」这个骨架仍是你写死的。再往前一步——连骨架也交给模型——就是 agent。

ReAct：学术起点，如今已内化进模型

今天的 agent loop 在学术上的源头是 2022 年的 ReAct（Reasoning + Acting）：让模型交替生成「推理痕迹」和「行动指令」，行动的观察结果再喂回推理。当年这需要精心设计 prompt 模板；如今主流模型都经过原生 tool-use 训练，「想一步、做一步、看结果、再想」已经是模型的内置行为，不再需要你手工搭 ReAct 脚手架。这是理解后文「bitter lesson」的第一个伏笔：昨天的框架功能，会变成今天的模型能力。

把一个成熟 agent 产品（比如 Claude Code）解剖开，会得到九层。本章给出地图，后面每章拆一层。

一个重要的心智模型：这九层里只有 L1 是「AI」，其余八层全是工程。这就是为什么 2025 年行业把这门手艺改叫 agent engineering——LangChain 对 1,340 名从业者的调研显示，57.3% 的组织已有 agent 跑在生产环境[10]，而他们的瓶颈不是模型，是工程：质量（约三分之一受访者的首要障碍）和延迟（约 20%）[10]。

剥掉所有产品包装，Claude Code 和一切同类产品的心脏是同一段代码：一个把「模型决策」和「工具执行」连起来的 while 循环。

OpenAI 的官方指南把这一点说得很直白：每种编排方式都需要「run」的概念——一个让 agent 持续运行直到满足退出条件的循环；退出条件包括产出最终输出、模型不再调用工具直接回复、出错、或达到最大轮数。「while 循环的概念是 agent 运转的核心」[9]。

def run(task):
    messages = [system_prompt, task]
    while True:
        reply = llm(messages, tools=TOOLS)      # ① 模型决策
        if not reply.tool_calls:                # ② 不调工具 = 任务完成
            return reply.text
        for call in reply.tool_calls:           # ③ 执行工具
            result = execute(call)              #    （在沙箱/权限系统里）
            messages.append(tool_result(result))# ④ 结果回填上下文
        # ⑤ 回到 ① —— 模型看到结果，决定下一步

这五步看起来平平无奇，但 agent 的全部魔法和全部难题都在这里：魔法在于模型每轮都能看到真实环境的反馈（文件内容、命令输出、报错信息），从而自我纠错；难题在于 messages 数组只增不减——上下文膨胀（§04）、单步错误随轮数累积（§08）、token 成本线性上涨（§10），全是这个循环的副产品。

模型层的四块积木

Tool calling（函数调用）解决「自然语言意图 → 机器可执行调用」的转换问题。你向 API 声明一组带 JSON Schema 的工具，模型在需要时输出结构化的调用请求（工具名 + 参数），由你的代码执行后回填结果。没有它，就只能靠正则从自由文本里抠指令——这正是 2023 年以前 agent 脆弱的原因。今天它是模型的原生能力，所有主流 API（Anthropic、OpenAI、Gemini）的接口形态已高度趋同。

Structured output 解决「输出必须可被程序消费」的问题：约束模型输出符合给定 schema 的 JSON，用于分类、提取、子 agent 向上汇报等场景。其原理是约束解码（constrained decoding）——在采样时屏蔽不符合语法的 token，从机制上保证合法性，而不是「请求模型配合」。

Streaming 解决「延迟体验」问题。agent 单轮动辄几十秒，把 token 逐个流出来（以及把工具调用过程实时展示出来）是产品体感的生死线——这也是为什么所有 agent 产品的 UI 都在做「过程可见」。

模型选择有一套被验证过的方法论：先用最强模型把任务跑通、建立性能基线，再逐个环节尝试换小模型并用 eval 验证是否仍达标——而不是一开始就用小模型省钱，否则你永远不知道失败是因为模型不行还是系统设计不行[9]。成熟形态是大小模型分工：主决策用旗舰模型，子任务/摘要/分类用轻量模型（§10）。

如果说 2023 年的关键词是 prompt engineering，2025 年之后就是 context engineering。Anthropic 的定义：prompt 工程是一次性的离散任务，而上下文工程是每次推理时都要做的迭代工作——策划进入模型的最优 token 集合[3]。

为什么必须管：context rot

直觉上「窗口越大越好，塞满就行」，但实测不成立。Chroma 的研究和 Anthropic 的工程实践都确认了 context rot（上下文腐烂）：随着上下文 token 量增加，模型准确回忆其中信息的能力会下降[3][13]。根源在 Transformer 架构本身——每个 token 要和所有其他 token 计算注意力，n 个 token 就是 n² 对关系；上下文越长，注意力被「摊薄」得越厉害。所以正确的心智模型是：上下文是边际收益递减的有限资源，模型有一个「注意力预算」[3]。窗口是工作台，不是仓库——台面越乱，手上的活越糙。

对 agent 来说这是致命问题：循环每转一圈，工具结果就往 messages 里堆一层。一个长任务跑几十轮，上下文里 90% 是过期的工具输出，真正重要的任务目标和关键决策被淹没——这就是「长任务漂移」的主要成因之一。

四类手段

① Compaction（压缩重启）。对话逼近窗口上限时，把历史总结成摘要、用摘要重启新窗口。Claude Code 的实现会保留架构决策、未解决的 bug 和实现细节，丢弃冗余的工具输出[3]。关键设计点是「保什么、丢什么」——丢错了，agent 会忘记自己为什么在做这件事。

② Context editing（过期内容清除）。比整体压缩更细粒度：自动把上下文里过期的工具调用和结果清掉，保留对话主干。Anthropic 2025 年 9 月把它做成了平台功能[4]。在其内部评估中，仅启用 context editing 就让复杂多步任务性能提升 29%——少了垃圾，注意力更聚焦，删上下文反而提分[4]。

③ Memory（窗口外的持久层）。窗口内是工作记忆，跨会话的长期记忆要落到窗口外。当前的主流形态是文件式记忆：模型通过工具对一个专用目录里的文件做增删改查，目录存在开发者自己的基础设施里、跨会话持久[4]。Claude Code 的 CLAUDE.md、memory tool、Manus 的「文件系统即终极上下文」都是这个思路。Anthropic 实测：memory tool + context editing 组合让多步任务性能比基线提升 39%[4]。

④ Just-in-time 加载。与其把所有可能用到的资料预先塞进窗口，不如只保留轻量「指针」（文件路径、查询语句、链接），运行时用工具按需加载[3]。这是 §06 里 agentic search 路线的理论依据。

Prompt caching：上下文工程的经济学底座

Agent 的每一轮循环都要把全部历史重发给模型——不做缓存，第 30 轮的输入是前 29 轮的总和，成本是平方级的。Prompt caching 解决这个问题：服务端缓存已处理过的前缀的内部状态（KV cache），下次请求若前缀完全一致则直接复用。以 Anthropic 为例：缓存写入约为正常输入价的 1.25 倍，命中读取只要 0.1 倍，默认 TTL 5 分钟、每次命中自动续期。十倍价差意味着对 agent 这种「长前缀 + 增量追加」的负载，缓存命中率直接决定毛利。

由此推出 agent 设计的一条铁律——上下文必须 append-only（只追加）：system prompt 和工具定义放最前且保持稳定，绝不在 prompt 里放时间戳这类每次变化的内容，不回头修改历史消息——任何一处前缀变动都会让缓存从那一点起全部失效。Manus 团队直言「KV 缓存命中率是生产环境 agent 最重要的单一指标」[18]，他们为此甚至不从工具列表里删工具（会改变前缀），而是用 logits mask 屏蔽不可用的工具。行业现状是惊人的浪费：Datadog 对真实生产 trace 的分析显示，69% 的输入 token 花在 system prompt 上，但只有 28% 的 LLM 调用出现缓存命中——大量团队在为同样的指令反复全价付费[11]。

Agent 的能力上限由模型决定，下限由工具决定。Anthropic 把「工具的接口设计」称为 ACI（agent-computer interface），并认为它值得与人机界面（HCI）同等的设计投入。

工具设计：被低估的高杠杆环节

一个反直觉的事实：Anthropic 在做 SWE-bench（代码修复基准）的 agent 时，花在优化工具上的时间超过了优化整体 prompt 的时间[1]。原则是站在模型的角度审视工具：参数含义是否一目了然？会不会逼模型干「容易出错的精细活」（比如精确数行号）？格式是否接近模型在训练数据里常见的形态？Anthropic 后续的《Writing effective tools for agents》补充了几条生产级经验[5]：

• 合并而非罗列：把高频组合操作合并成一个工具，而不是暴露 20 个原子 API 让模型自己编排；
• 返回「有意义的上下文」：工具结果要为下一步决策服务，而不是原样转储 5000 行 JSON——token 效率是工具的硬指标；
• 命名空间：工具多了要用前缀分组（如 github_*、db_*），降低选错率；
• 用 agent 评估工具：让 agent 在真实任务上用工具，看 transcript 里它在哪卡壳，迭代工具而不是怪模型。

MCP：工具生态的 USB-C

工具设计解决「单个工具好不好用」，MCP（Model Context Protocol）解决「工具生态怎么互通」。它要消灭的是 N×M 集成矩阵：N 个 agent 应用 × M 个外部系统，每对都写一遍胶水代码。MCP 把这变成 N+M——工具方实现一次 MCP server，任何支持 MCP 的客户端（Claude Code、各 IDE、各 agent 框架）即插即用。2024 年 11 月由 Anthropic 开源，随后 OpenAI、Google 等相继支持，现已是事实标准，规范本身持续演进（最新版 2025-11-25[12]）。协议是客户端–服务器结构，server 向 agent 暴露三类东西：tools(可调用的操作）、resources（可读取的数据）、prompts（预置的提示模板）。

MCP 也带来了新问题：接上十个 server，几百个工具定义会先把上下文吃掉一大块（每个工具的 schema 都要进窗口）。Anthropic 给出的解法是把 MCP 工具呈现为代码 API——让 agent 写代码去调用这些接口、按需加载工具定义，而不是把所有定义平铺在上下文里；其示例场景中上下文从 15 万 token 降到 2 千，降幅 98.7%[6]。这预示了一个趋势：code execution 正在成为 agent 的「万能工具」——很多过去靠专用工具做的事，正收敛为「让 agent 在沙箱里写代码完成」。

沙箱：让 agent 敢于行动的前提

一旦 agent 能执行任意命令和代码（coding agent 的基本能力），「它会不会 rm -rf 我的机器」就不再是玩笑。沙箱解决爆炸半径问题，主流方案是一个隔离强度递增的谱系[21]：

实践中的选型逻辑：本地开发工具用 OS 级约束 + 权限审批（够用且零部署）；云端多租户跑不可信代码（agent 平台、code interpreter 类产品）直接上 microVM 或托管沙箱服务（E2B 等），把「逃逸」从应用层问题变成基础设施承诺。

Computer use 与 browser use：兜底的通用工具

没有 API 的系统怎么办？让 agent 像人一样看屏幕、动鼠标键盘（computer use），或通过 CDP/Playwright 驱动浏览器 DOM（browser use）。这是覆盖面最广、也最慢最贵最脆的工具层级。成熟产品的共识是分层兜底：有专用 API 用 API，网页用浏览器协议，实在没有才用像素级操作。OpenAI Operator、Claude 的 computer use、各类 browser-use 开源框架都在这一层。

知识装不进窗口，就要按需取。两条路线：预先建索引（RAG），或给 agent 搜索工具让它自己找（agentic search）。2025 年的风向是后者在 agent 场景大幅扩张。

经典 RAG 的流水线：文档切块（chunking）→ 算 embedding → 存向量数据库（Pinecone、Qdrant、Weaviate、pgvector、Chroma……）→ 查询时取语义最近的 top-k 块塞进上下文。它解决的是「海量非结构化知识的语义检索」：客服知识库、法律文书、产品文档这类场景仍是 RAG 的主场。代价是一条不短的工程链：切块策略、embedding 模型选型、索引同步更新、相关性调优，每一环都可能成为质量瓶颈。

Agentic search 走另一条路：不预建语义索引，给 agent 真正的搜索工具（grep、glob、SQL、站内搜索 API），让它像工程师一样迭代式地找——搜一下、看结果、换关键词再搜、顺着引用跳。理论依据正是 §04 的 just-in-time 原则：上下文里只保留轻量指针，运行时按需加载[3]。最有代表性的实证是 Claude Code 没有任何 embedding 索引——纯靠 grep/glob 在大型代码库上工作，效果反而优于「代码库向量化」方案：代码是高度结构化的文本，符号名精确匹配 + 模型的多轮推理，比语义相似度更可靠，还省掉了索引的维护成本和泄露面。

判断标准可以归结为一句话：你的数据有没有现成的「可迭代搜索面」。代码有（文件系统 + grep）、数据库有（SQL）、网页有（搜索引擎）——这些场景 agentic search 几乎总是更优；纯散文本没有，才需要 RAG 给它造一个语义搜索面。两者也常常组合：RAG 做粗召回，agent 再用工具精读核实。

「要不要多 agent」和「要不要框架」是 agent 架构讨论中被问得最多的两个问题。两家头部实验室的答案都偏保守，而且有数据支撑。

单 agent 优先，多 agent 看任务形态

OpenAI 的建议非常明确：先把单 agent 的能力榨干——多 agent 带来直观的关注点分离，但也带来复杂度和开销；只有当单 agent 无法遵循复杂指令、或持续选错工具时才拆分。拆分后的编排只有两大类模式：Manager（中心 agent 把其他 agent 当工具调用）和 Decentralized（agent 之间互相移交控制权，handoffs）[9]。

什么时候多 agent 真有效？Anthropic 的研究系统给出了最硬的数据：在广度优先的研究任务上，Opus 4 做 lead + Sonnet 4 做 subagent 的多 agent 系统，比单 agent Opus 4 高出 90.2%，并行化让复杂查询的研究时间最多缩短 90%[2]。但同一篇文章也给出了两个泼冷水的数字：多 agent 系统的 token 消耗是聊天的约 15 倍（单 agent 约 4 倍）[2]；且 subagent 必须拿到目标、输出格式、工具边界都写清楚的任务说明，否则就会重复劳动、漏活、找不到信息[2]。

更本质的规律藏在任务形态里：读任务好并行，写任务难并行。研究、审查、搜索这类只读任务，天然可以切分给互不干扰的 subagent；而写代码、改文件这类有状态的任务，并行就要面对冲突合并——这是为什么 Claude Code 主体是单线程循环 + 只在搜索类子任务上开 subagent（§11）。subagent 的另一个常被忽略的价值是上下文隔离：脏活（翻几百个文件）在 subagent 的窗口里干，主 agent 只收结论，保护自己的注意力预算。

框架对比：先想清楚要不要，再想用哪个

Anthropic 的官方立场值得先放在前面：建议从直接调 LLM API 开始——很多模式几行代码就能实现，框架的额外抽象层会掩盖底层 prompt 与响应、增大调试难度[1]。行业数据也支持「框架不是必需品」：框架采用率一年翻倍后，2026 年初也只有约 18% 的组织在用[11]——而 57.3% 的组织已有 agent 在生产[10]，意味着大量生产 agent 是直接 API + 自写循环。

Agent 的两类失败要分开治理：自己犯错（可靠性），和被人弄犯错（安全）。前者靠工程兜底，后者——说实话——目前没有根治方案，只能靠架构性防御。

可靠性：与错误累积作战

单步 95% 的正确率，20 步连乘只剩 36%。这道乘法是 agent 工程的核心敌人[1]，对策分三层：

环境反馈自纠错——最重要也最容易被忽略的一层：让每个动作的真实结果（编译报错、测试输出、HTTP 状态码）回到上下文，模型就能发现并修正自己的错误。agent 比单次调用可靠，靠的正是这个反馈回路，所以工具结果的信息质量（§05）直接决定纠错能力。程序化防线——工具参数 schema 校验、瞬态错误重试、敏感操作幂等设计、最大轮数限制（防止无限循环烧钱）。Guardrails 分层——OpenAI 指南的清单：相关性/安全分类器拦截跑题和越狱输入、PII 过滤、moderation、按风险给工具分级，高危操作触发额外检查[9]。

Human-in-the-loop（HITL）是最后一道闸，也是冷启动期的标配：高风险动作（删数据、对外发送、花钱）暂停等人批准。Claude Code 的权限系统是教科书式实现——只读操作放行，写文件、跑命令按权限模式逐项审批，用户可沉淀白名单。设计要点是审批要有信息量（让人看清楚将要发生什么）且不能太频繁（否则人会麻木地一路点是，闸门形同虚设）。

安全：prompt injection 与致命三要素

Prompt injection 是 OWASP GenAI 风险榜的第一位（LLM01）[15]：攻击者把指令藏在 agent 会读到的内容里——网页、邮件、文档、甚至代码注释——模型把数据当成了指令。根本困境在于 LLM 的架构里指令和数据共享同一条通道，没有 SQL 参数化查询那样的硬隔离。所有「请忽略不可信内容中的指令」式防御都只是概率性缓解。

所以工程上最有用的框架是 Simon Willison 的致命三要素（lethal trifecta）[14]：当一个 agent 同时具备 ① 访问私有数据、② 接触不可信内容、③ 对外通信的能力时，数据窃取只是时间问题——注入的指令可以命令 agent 读取机密并发出去。防御思路不是「更聪明的过滤」，而是架构上保证三要素不同时成立。

落地的防御清单：最小权限（agent 的凭证只授予任务必需的最小范围，且与用户凭证隔离）；secrets 不进上下文（密钥放执行环境的环境变量/秘钥管理，模型只见占位符——进过上下文的内容就可能被诱导复述出去）；不可信内容降级处理（读网页/邮件的 agent 默认不给对外写权限）；对外动作过 HITL。

Agent 是非确定性系统：同样输入，两次运行路径可能完全不同。没有 eval，你的每次「优化」都是在掷骰子；没有 tracing，你连骰子掷出了什么都看不见。

评估：从 benchmark 到自家 eval

公开 benchmark 负责回答「模型/方案选哪个」：SWE-bench Verified（真实 GitHub issue 修复，coding agent 事实标准）、tau²-bench（Sierra 出品，模拟用户对话 + 业务政策约束，客服 agent 标准，考验「既要完成任务又不能违规」[17]）、Terminal-Bench（终端任务）、GAIA/BrowseComp（通用助理与深度网页搜索）。它们的共同点是评结果而不评过程：代码以测试通过为准，对话以最终数据库状态为准。

但 benchmark 不能替代你自己的 eval。Anthropic 的《Demystifying evals》给出务实路径[8]：从十几二十个真实失败案例起步（别等「完备测试集」）；按任务选 grader——可程序判定的用代码判（测试通过、状态正确），主观质量用 LLM-as-judge 加 rubric，关键场景留人工抽检；用 pass@k 应对非确定性（跑 k 次看通过率而非单次定生死）；除了对错还要看轨迹——步数、token 花费、是不是绕了远路。eval 集应该随生产失败案例持续生长，它就是 agent 工程的回归测试套件。

可观测：OTel 正在统一标准

Agent 的 debug 单元不是日志行，是 trace——一次任务的完整轨迹树：每轮 LLM 调用的输入输出、每次工具调用的参数结果、token 与延迟。主流工具是 LangSmith（LangChain 系）、Langfuse（开源自托管友好）、Braintrust（eval+tracing 一体）；底层标准正在被 OpenTelemetry 的 GenAI 语义约定统一——span 怎么命名、token 怎么计、agent 调用怎么嵌套，都有了厂商中立的规范[16]，意味着观测数据不必锁死在某家平台。

行业数据印证了这一层的「标配」地位：89% 的组织已有某种形式的 observability，62% 有能检查单步的精细 tracing；在已上生产的团队里，两个数字分别升到 94% 和 71.5%[10]。换句话说：没有 tracing 的团队基本到不了生产。

Agent 产品的成本结构和聊天产品完全不同：单 agent 的 token 消耗约是聊天的 4 倍，多 agent 系统约 15 倍[2]。不做成本工程，PMF 再好也会被账单杀死。

但有一个微妙的事实让「省钱」变得不简单：Anthropic 在搜索类任务上发现，token 用量、工具调用次数、模型选择三个因素解释了 95% 的性能方差，其中 token 用量单独解释 80%[2]——agent 的性能在很大程度上就是「烧了多少推理预算」。所以成本工程的正确目标不是少烧，而是不浪费：把每个 token 烧在产生信息增益的地方。三个抓手：

• 缓存优先。0.1 倍的缓存读价 + agent 负载天然的长公共前缀 = 最大的一笔可白拿的折扣。append-only 上下文、稳定 system prompt（§04）。行业里 72% 的调用没有任何缓存命中[11]，意味着多数团队还没拿这笔钱。
• 模型路由。用 §03 的方法论（最强模型建基线 → 换小模型验证[9]）把任务分给不同档位：主决策用旗舰，subagent/摘要/分类用中小档。Anthropic 研究系统的 Opus lead + Sonnet workers 就是范本[2]。
• 上下文减肥。69% 的输入 token 是 system prompt[11]——审计你的指令和工具定义；工具返回做裁剪；context editing 清过期结果。性能（§04）与成本在此再次合流：垃圾 token 既花钱又毒害注意力。

部署层面再加两条常识：长任务一律异步化（任务队列 + 通知，而不是挂着 HTTP 连接）；按用户/任务设 token 预算上限，防止失控循环烧穿钱包——「最大轮数」既是可靠性手段也是成本手段。

看五个产品的公开架构，你会发现它们是同一套九层栈的不同权重分配——而最成功的那个，恰恰是架构最简单的。

Claude Code：极简主义的胜利

公开分析显示其核心是单线程主循环 + 扁平消息历史[19]：一个 loop，没有复杂的 agent 图，没有向量索引（纯 agentic search，§06），subagent 只允许一层（防止层级失控），用 TODO 列表对抗长任务漂移，用 compaction 对抗窗口耗尽，用权限系统兜安全。它的设计哲学被反复引用：do the simplest thing that works——把复杂度留给模型，把工程做在 harness（上下文、工具、权限）上。这套 harness 后来以 Claude Agent SDK 开放[7]。这是「bitter lesson」在 agent 设计上的体现：少搭脚手架，赌模型变强——模型每升级一代，复杂 scaffolding 的相对价值就贬值一截，而简单 harness 直接吃到全部红利。

Manus：上下文工程的极致流派

通用 agent Manus 的工程复盘是上下文工程最好的实战教材[18]：KV 缓存命中率奉为第一指标；上下文严格 append-only；工具不可用时用 logits mask 屏蔽而不是从列表删除（保前缀稳定）；文件系统当作无限大的外部上下文（大内容写文件、窗口里只留路径）；以及著名的「todo.md 复述」——agent 不断重写任务清单，把全局目标顶到注意力最新鲜的窗口末端，对抗长任务漂移。

Devin、Cursor、Codex、Copilot：形态之争

Cursor 押注「人机协作」：agent 嵌在 IDE 里，人随时看见、随时接管，短反馈回路掩盖错误累积。Devin 押注「自主外包」：云端 VM 里自带规划器、浏览器、shell 的全自主长任务工程师——同时也最大程度暴露在错误累积面前，这是它口碑两极的根源[23]。OpenAI Codex 押注「云端并行」：每个任务一个隔离沙箱，开发者像发 PR 一样批量派发任务。GitHub 则干脆把平台做成多 agent 市场：Agent HQ 让 Claude、Codex 等不同厂商的 agent 在同一个工作流里被指派[20]——agent 本身在平台化、可替换化。

把全文收束成可执行的判断。先按场景给选型，再给一条从 0 到 1 的路径。

从 0 到 1 的路径

1. 徒手写一个 agent loop（§03 的伪代码，接 2–3 个真工具），不用任何框架——这是性价比最高的一步；
2. 给它接上权限审批和沙箱，让它敢做有副作用的事（§05、§08）；
3. 接 tracing，攒 20 个失败 case 做成第一版 eval（§09）；
4. 开始做上下文工程：稳定前缀吃缓存、工具结果裁剪、加 compaction（§04）——这一步前后的成本和质量差异会让你震惊；
5. 需要时再考虑 subagent 和框架（§07），用 eval 验证每次复杂度增加是否真的买到了效果。

最后用三句话带走全文：① Agent = 模型 + while 循环 + 工具，其余一切都是让这个循环可靠、便宜、安全的工程。② 上下文是稀缺资源，性能问题和成本问题在它身上是同一个问题。③ 复杂度必须用 eval 验证的效果来购买——从最简单的方案开始，赌模型变强。

本文由多源深度调研产出：26 个来源、129 条候选事实，其中 25 条核心结论经三票对抗性交叉验证（全部通过，0 条被否决）。技术事实与数字核实于 2026-06-12；产品功能与价格以官方文档为准。