LLM - 从 Prompt 到 Context：2026 Agent 时代的核心战场

文章目录

概述
[一、从 49% 到 80%：模型质变与成本逻辑重构](#一、从 49% 到 80%：模型质变与成本逻辑重构)
- [1. SWE-bench Verified：指标背后的含义](#1. SWE-bench Verified：指标背后的含义)
- [2. 从 token 单价到任务总成本](#2. 从 token 单价到任务总成本)
- [3. 安全能力的升级：Prompt Injection 不再是绝对红线](#3. 安全能力的升级：Prompt Injection 不再是绝对红线)
[二、2026 三大核心方向：长时运行、GUI 操作、垂直深耕](#二、2026 三大核心方向：长时运行、GUI 操作、垂直深耕)
- [1. Long‑running Agents：从小时到周级任务](#1. Long‑running Agents：从小时到周级任务)
- [2. Computer Use：让 Agent 也会"用电脑"](#2. Computer Use：让 Agent 也会“用电脑”)
- [3. 垂直领域：安全、金融与办公自动化](#3. 垂直领域：安全、金融与办公自动化)
[三、Agent 本质：从预定义 Workflow 到"模型 + 工具 + 循环"](#三、Agent 本质：从预定义 Workflow 到“模型 + 工具 + 循环”)
- [1. Workflow：人写流程，模型填空](#1. Workflow：人写流程，模型填空)
- [2. Agent：模型在运行时做决策](#2. Agent：模型在运行时做决策)
[四、Context Engineering：Agent 时代的核心功夫](#四、Context Engineering：Agent 时代的核心功夫)
- [1. 从一次性 Prompt 到生命周期 Context](#1. 从一次性 Prompt 到生命周期 Context)
- [2. Goldilocks Zone：指令的"刚刚好区间"](#2. Goldilocks Zone：指令的“刚刚好区间”)
[五、工具设计：比"调 Prompt"更值得花时间的地方](#五、工具设计：比“调 Prompt”更值得花时间的地方)
- [1. 工具描述就是高优先级 Prompt](#1. 工具描述就是高优先级 Prompt)
- [2. 严格区分相似工具的数据范围](#2. 严格区分相似工具的数据范围)
- [3. Tool Use Examples：用案例教模型"怎么用"](#3. Tool Use Examples：用案例教模型“怎么用”)
- [4. Progressive Disclosure：按需暴露工具](#4. Progressive Disclosure：按需暴露工具)
六、长任务与长上下文：三大关键策略
- [1. Compaction：必要之恶，但目前仍然必需](#1. Compaction：必要之恶，但目前仍然必需)
- [2. Memory：让 Agent 学会"做笔记"](#2. Memory：让 Agent 学会“做笔记”)
- [3. Sub‑agent：用分工与报告对抗上下文爆炸](#3. Sub‑agent：用分工与报告对抗上下文爆炸)
[七、终局：给 Agent 一台电脑，让它"用代码干完所有事"](#七、终局：给 Agent 一台电脑，让它“用代码干完所有事”)
- [1. Programmatic Tool Calling：代码即能力](#1. Programmatic Tool Calling：代码即能力)
- [2. Claude Agent SDK：把循环与基础设施框架化](#2. Claude Agent SDK：把循环与基础设施框架化)
[八、如何在 2026 年落地 Agent：一些实践建议](#八、如何在 2026 年落地 Agent：一些实践建议)

概述

2025 年，大模型 Agent 从概念走向爆发，但绝大多数产品依旧停留在 Demo 与 PoC 阶段，真正在线上稳定跑长任务的系统寥寥无几。 Anthropic 在 2025 年 AWS re:Invent 上给出了一条相对清晰的 2026 Agent 终局路线：更强的模型能力、可长时运行与会"用电脑"的 Agent，以及以 Context Engineering 为核心的方法论。

接下来我们将尝试站在工程角度，拆解 Anthropic 的关键信号，并结合开发者视角，回答三个问题：

Agent 真正的形态是什么，不同于传统 Workflow 在哪里
Context Engineering 到底在解决什么问题，如何落到工程实践
2026 年值得提前布局的 Agent 能力与场景有哪些

一、从 49% 到 80%：模型质变与成本逻辑重构

1. SWE-bench Verified：指标背后的含义

在软件工程领域，SWE-bench Verified 被视为最接近真实开发场景的权威评测之一。 2024 年底 Claude Sonnet 3.5 V2 在该基准上的得分约为 49%，到 2025 年底 Claude Opus 4.5 已经提升到 80%。

这 31 个百分点，不只是"刷题刷出来的分数"，而是几个关键变化的折射：

模型可以独立完成大部分中低难度 bug 修复任务，从"智能建议"变成"能真正提交 PR 的队友"
对复杂代码库的理解能力显著提升，跨文件、跨模块推理能力更强，不再仅仅依赖单文件上下文
复杂指令下的执行可靠性提高，减少了"明明说懂了，结果写反了"的情况

这直接决定了 Agent 在真实项目中的"可托付程度"：你究竟敢不敢让它一个人跑 4 小时，然后指望它交付一个能跑的版本。

2. 从 token 单价到任务总成本

当模型能力跨过某个阈值后，成本评估逻辑会发生质变。

过去常见的做法是：

对比不同模型的"每百万 token 单价"；
预估一个月要用多少 token，乘一下得出预算。

这种思路在模型能力差异不大的年代还勉强可用，但在 49% → 80% 的跃迁之后就失效了。

更合理的视角是任务总成本：

假设一个复杂编程任务
- 旧模型：成功率 50%，需要来回反复问，多轮澄清，累计 10 万 token
- 新模型：成功率 80%，规划更清晰，错误更少，5 万 token 搞定
即便新模型 token 单价翻倍，任务总成本依然更低，还节省了人力时间与沟通成本。

Anthropic 的判断是：2026 年企业必须从"单价思维"转向"任务成本思维"，否则在模型选型上会做出错误决策。

3. 安全能力的升级：Prompt Injection 不再是绝对红线

Prompt Injection 一直是企业在上 Agent 时最担心的一类攻击：只要把恶意指令埋进网页、文档或用户输入，就可能让模型"洗脑"，执行越权操作或泄露敏感信息。

Opus 4.5 在这一点上做了专门强化，据公开信息，已经能够抵御 90% 以上的常见 Prompt Injection 攻击样式。对于金融、政企、安全等高敏感场景，这意味着 Risk Owner 可以更有底气地放行试点项目。

二、2026 三大核心方向：长时运行、GUI 操作、垂直深耕

Anthropic 对 2026 年的判断，不再停留在"更大 Context、更强模型"这些参数层面，而是明确指向三条路线。

1. Long‑running Agents：从小时到周级任务

当下大多数 Agent 还能勉强支撑"单次会话级任务"，比如连续调试一个功能、回答一轮长对话，但很难支撑"周级任务"。 Anthropic 提出的 Long‑running Agents 目标，是把 Agent 的运行时长从几小时推到数天乃至数周。

设想一个场景：

给 Agent 一个完整项目 brief：
- 需求说明、粗略架构约束、技术栈偏好
让它在一周内完成：
- 需求澄清、架构草案
- 代码实现与单测
- 基本部署脚本
人类开发者主要承担审阅、关键决策与 code review 角色

要支撑这样的场景，关键不再是"上下文窗口多大"，而是：

如何在有限窗口内长期维持对目标与约束的记忆
如何在长任务中处理失败重试、状态恢复与中断续跑
如何分阶段产出中间物（设计文档、接口定义等），为后续步骤提供锚点

这直接引出后文的 Context Engineering 与 Memory 设计问题。

2. Computer Use：让 Agent 也会"用电脑"

现实世界里，仍有大量业务流程被锁在 GUI 应用里：老旧 ERP、财务系统、图形设计工具、桌面报表软件、只能本地访问的内网后台等。这些系统没有友好的 API，对传统"调用 REST 工具"的 Agent 架构极不友好。

Anthropic 的方案，是为模型加上一种类似"远程桌面+人类视觉"的能力：

让 Agent 看截图，理解窗口结构、按钮位置和文本内容
通过模拟鼠标移动、点击和键盘输入来操作软件
在缺乏 API 的系统上，用 GUI 操作完成数据录入、导出、查询、配置等任务

当前版本的 Computer Use 在效率上还不算理想，Cal 甚至吐槽"看着模型慢吞吞点鼠标会非常抓狂"。但随着模型推理速度和操作策略的优化，2026 年这块的速度预期会有数量级提升，覆盖日常办公软件是可见的里程碑。

3. 垂直领域：安全、金融与办公自动化

在"横向能力"之外，Anthropic 明确选了三条垂直主赛道：

网络安全（Cybersecurity）
- 代码审计与漏洞扫描
- 日志分析与攻击行为识别
- 自动生成修复建议与加固方案
金融服务
- 财务报表解析与建模
- 量化数据分析、策略回测
- 合规检查与风险提示
办公自动化
- PPT 自动生成与美化
- Excel 数据处理与可视化
- 文档撰写、总结与格式统一

这三条赛道具备共同特点：高价值、高结构化数据密度、对自动化有强烈需求。对开发者来说，如果在 2026 年要"赌一条赛道"，围绕这三类场景做垂直 Agent 产品，是相对更稳的方向。

三、Agent 本质：从预定义 Workflow 到"模型 + 工具 + 循环"

要理解后面所有工程实践，必须先厘清一个基本问题：Agent 与传统 Workflow 有什么根本不同？

1. Workflow：人写流程，模型填空

传统 LLM 应用，大多可以用"增强版流程引擎"来类比：

开发者预先定义一套流程图：
- 节点 A：问候与身份确认（一个 prompt）
- 节点 B：问题分类（另一个 prompt）
- 节点 C1/C2/C3：不同子流程（多个 prompt）
中间用 if-else 或规则引擎判断下一步走向

这种模式有它的价值：

简单、可控、易于做"流程配置平台"
适合问答型、表单型、流程固定的场景

但一旦业务复杂度上来，问题立刻出现：

需要覆盖 50 种业务场景，就可能要写上百个 prompt 和分支
任一环节的异常或理解偏差，很容易"传染"到整个流程
当需求频繁变化时，维护成本雪崩

2. Agent：模型在运行时做决策

Anthropic 给 Agent 的定义可以概括为一句话：Agent = 模型 + 工具 + 循环。

模型：具备规划、反思与自我纠错能力
工具：与外部世界交互的接口（API、数据库、文件系统、代码执行环境、GUI 操作等）
循环：允许模型多轮调用工具，根据工具返回结果持续调整计划，直到达到目标或主动停止

关键区别在于：

Workflow：决策权在开发者手里，所有路径与分支提前写死在流程图里
Agent：决策权在模型运行时，开发者只定义目标、工具与安全边界

这样一来，Agent 可以：

在遇到未预见的输入时，临机规划新路径
对错误结果进行自检和替代尝试，而不是直接失败
在不爆炸流程分支的前提下，覆盖更多长尾场景

Developer 的角色也从"写流程的人"变成"提供高质量工具和良好上下文的人"。

四、Context Engineering：Agent 时代的核心功夫

2024 年火的是 Prompt Engineering，大家在研究各种花式指令模板；到了 2025--2026 年，重心正快速转向 Context Engineering。

1. 从一次性 Prompt 到生命周期 Context

Prompt Engineering 关注的是：单次调用时，怎么写这段指令更好。

而一个真实的 Agent 任务通常包含几十上百次调用：

不同阶段的子目标提示
工具调用参数生成
失败后的反思与重试
长任务中的阶段性总结

Context Engineering 面对的是整个生命周期的信息管理问题：

System Prompt：给 Agent 的基础人格与行为准则
工具描述与使用示例：作为高优先级 Prompt 一直驻留在上下文中
Memory：在多轮、长时任务中，什么信息需要跨窗口保存
Compaction 与窗口调度：什么时候压缩、压缩什么、以什么粒度压缩

本质上，Context Engineering 是 Agent 世界的"信息架构设计"。

2. Goldilocks Zone：指令的"刚刚好区间"

Cal 在演讲中提出了一个非常实用的概念：Goldilocks Zone------指令既不过长也不过短，刚刚好。

两种常见极端：

过长：
- 把 32 页 SOP 一股脑儿塞进 System Prompt
- 密密麻麻的 if-else 逻辑，试图穷举所有边界
- 结果：模型被细节淹没，难以抽取真正重要的约束
过短：
- 三两句口号式描述：
  - "你是一个严谨的客服机器人，请专业、友好地回答问题。"
- 结果：模型不知道哪些话可以说、哪些必须回避，也不清楚优先级

所谓 Goldilocks Zone，更偏向"最小但足够的指令"：

清楚描述：
- 任务目标与不变约束（安全、合规、权限边界）
- 输出风格与形式（JSON、Markdown、代码片段等）
刻意避免：
- 冗长的伪代码
- 复杂 if-else 与分支穷举
- 不断叠加的"不许这样""不许那样"式补丁

一个简单的自检方法是：

把 System Prompt 发给一个对业务不熟悉的同事，让他用人类视角读一遍。能快速说出"你是谁、你要干什么、不能干什么、怎么干"，说明大致合格；如果连人都看不明白，模型大概率也不行。

五、工具设计：比"调 Prompt"更值得花时间的地方

在"模型 + 工具 + 循环"的架构中，工具定义质量往往是性价比最高的优化点。

1. 工具描述就是高优先级 Prompt

许多团队在定义工具时，只写了一个名字和一行简短描述，然后把大量精力花在"主 Prompt 调参"上，这其实是本末倒置。

要意识到：

工具描述会被直接拼进模型可见的上下文
模型依据这些文本判断何时、如何调用工具

因此一个高质量工具描述应该包含：

明确的用途说明：
- 这个工具解决什么问题，在哪些场景下适用
清晰的输入字段解释：
- 每个参数的语义、取值范围、默认行为
结果解释：
- 返回结果大致长什么样，模型应该如何使用

在工程实践中，经常能看到这样的现象：只改工具描述，不动主 Prompt，Agent 的稳定性就上了一个台阶。

2. 严格区分相似工具的数据范围

Anthropic 曾在内部踩过一个经典坑：Web Search 与 Google Drive Search 分别单测时效果都很好，合在一起后就经常混用。

问题根源不在模型，而在工具描述没讲明白：

Web Search：搜索互联网公开内容
Drive Search：在企业网盘或个人云盘中搜索文档

如果描述中没有突出"数据域"的差异，模型就只能模糊匹配"搜索相关内容"，自然容易乱用。

工程经验是：

工具命名中就显式写出数据域（如 search_public_web、search_internal_drive）
在描述里明确写出：
- "本工具只在公司网盘中搜索文档，不会访问互联网内容"
- "本工具只搜索公开网页，不会访问公司内部文件"

3. Tool Use Examples：用案例教模型"怎么用"

JSON Schema 能定义参数结构，却无法表达"真实使用习惯"。

一个常见例子：

工单系统有 priority 字段：low | medium | high | critical
仅靠 Schema，模型不知道：
- 生产环境 500 错误 → 必须 critical
- 普通功能建议 → 可以留空或 low

Tool Use Examples 的作用，就是通过几个典型场景，告诉模型：

不同情境下怎么填字段
哪些字段是强约束，哪些可以缺省

Anthropic 内部测试显示，在复杂工具上加上高质量示例后，调用准确率从 72% 提升到 90% 左右。

4. Progressive Disclosure：按需暴露工具

"所有工具一次性全塞给模型"是很多框架的默认做法，但在工具多、描述长的场景下非常致命。

Anthropic 在实践中测到的一个极端例子：光是工具定义，就占了 134K tokens，还没开始干活 Context 就快满了。他们在 Claude Code 中采用的策略是：

启动时只暴露"文件列表级别"的信息（有哪些文件、路径是啥）
需要时再调用 read_file 工具拉具体内容
唯一例外是 claude.md，作为用户长期指令与约定的存放地，一开始就加载

进一步，Anthropic 还实现了"工具搜索的工具"：让 Agent 自己先在一个轻量索引里找"可能需要的工具"，再按需加载完整定义。

结果非常夸张：

Context 占用从 77K tokens 降到 8.7K，下降约 85%
任务完成率从 49% 提升到 74% 左右

六、长任务与长上下文：三大关键策略

即便有 200K Context 窗口，也不足以支撑周级任务的一路"原始记录不丢弃"。 Anthropic 在实践中总结出三类核心策略。

1. Compaction：必要之恶，但目前仍然必需

Compaction 的思路很简单：

当上下文接近上限时
让模型对历史对话、代码、日志等做分层摘要
用更短的摘要替代原始内容，释放窗口空间

真正难的是写好压缩 Prompt：

保留哪些信息：任务目标、已尝试路径、关键中间结论、失败原因
舍弃哪些信息：细节性的日志、可随时重新拉取的原始数据

据公开信息，Claude Code 的压缩 Prompt 已经迭代了 100 多版，这恰恰说明这不是一次性写好的"提示词"，而是持续演化的工程模块。

2. Memory：让 Agent 学会"做笔记"

相比压缩，Memory（外部长时存储）是一种更优雅的方式。

核心思路：

给 Agent 一个简单的"文件系统"或 KV 存储
让它学会：
- 在任务推进过程中，把关键事实写成"笔记"存起来
- 每次任务恢复或窗口重建时，先读笔记，再继续推理

Anthropic 著名的 "Claude Plays Pokémon" 项目，就是用这种方式支撑起一个超长任务：玩完一整个宝可梦红版游戏。

游戏过程涉及数千次决策：
- 当前主线/支线任务是什么
- 哪些招式对哪些敌人有效
- 道具、资源与地图进度
Claude 没有依赖压缩，而是用 markdown 记笔记，每次重启上下文都先读笔记恢复记忆

更重要的是，Anthropic 正在把这种"会主动做笔记"的行为训练进模型本身，让记笔记变成默认能力，而不是每次都靠 Prompt 提醒。

3. Sub‑agent：用分工与报告对抗上下文爆炸

Sub‑agent（子代理）策略的核心是"分而治之"。

典型结构：

主 Agent：
- 负责整体规划与任务 orchestration
- 拆分子任务，分配给不同子 Agent
- 汇总子 Agent 报告，做决策与产出最终结果
子 Agent：
- 专注某类任务：代码勘探、日志分析、数据清洗等
- 拥有独立上下文，不被全局信息干扰
- 输出精炼报告，而不是一大坨中间过程

Anthropic 在 Claude Code 里最早尝试 Sub‑agent 是为了做并行处理，但发现模型目前还不擅长自己把任务分成真正可并行的原子单元，并行收益有限。相反，在探索式任务中，Sub‑agent 的价值非常明显：

修复杂 bug 时：
- 子 Agent A：专门负责扫描相关文件，理解模块结构
- 子 Agent B：专门分析报错日志、重现场景
- 主 Agent：基于两份报告综合制定修复方案

这样主 Agent 的上下文保持相对干净，不需要承载所有探索细节，只接收"压缩后的高价值信息"。

七、终局：给 Agent 一台电脑，让它"用代码干完所有事"

回到一个看似很大的问题：2026 年 Agent 的终局是什么？

Anthropic 给出的答案出乎意料地朴素：

给 Agent 一台电脑，让它通过写代码完成任何可以在电脑上完成的任务。

1. Programmatic Tool Calling：代码即能力

在 PPT、Excel 等办公任务上，Claude 并不是通过什么神秘的"生成 PPT API"工作的，而是通过写代码操作现有库：

用 Python 库生成和编辑 PowerPoint
用 JS/Python 操作 Excel 文件
用脚本调度图表生成、图片嵌入、文字排版

这背后的判断是：

任何计算机完成的任务，本质上都可以用代码表达
只要有足够丰富的库与工具，会写代码的 Agent 理论上可以覆盖几乎所有数字化工作场景

Programmatic Tool Calling 的特点是：

Agent 通过写代码组织整个任务
工具只是代码里的库调用，而不是一长串独立的"工具节点"
中间数据在代码环境内直接流转，最终只把结果呈现给用户

这比"把工具拼在流程图上"更通用、更强大，也更接近人类工程师的工作方式。

2. Claude Agent SDK：把循环与基础设施框架化

为了让开发者不必从零搭建 Agent 运行时，Anthropic 把 Claude Code 里打磨过的能力抽象为 Claude Agent SDK：

Agent 循环机制：计划---调用---反思---修正
权限与安全控制：文件访问、网络访问、代码执行沙箱
Memory 管理：持久化笔记、上下文重建
工具模板与最佳实践：描述规范、示例用法等

开发者可以在这个基础上：

自己定义领域工具（安全扫描、财务建模、合规检查等）
用 Context Engineering 把领域知识"嵌进" Agent 的信息流
把注意力从"怎么让 Agent 跑起来"转移到"怎么让它在我这个领域真正有用"

结合前文那句话：几乎所有的知识工作者都是在一台电脑前完成工作的。 一旦"给 Agent 一台电脑"成为现实，所有这些角色都能被一个统一的底层能力承载，只在工具与 Context 上呈现出差异。

八、如何在 2026 年落地 Agent：一些实践建议

站在开发者视角，结合前面的信息，可以提炼出几条相对务实的建议。

把"模型选型"从单价比较，升级到"任务总成本 + 安全能力 + 长任务稳定性"评估
不再迷恋复杂 Workflow，把更多精力放在：
- 高质量工具设计与示例
- 清晰、精简的 System Prompt 与 Context 结构
早早为 Long‑running 任务准备好：
- Compaction 方案（即便只是 MVP 版）
- 简单 Memory 机制（日志/markdown/数据库记录）
在选 Agent 框架时坚持几个底线：
- 可控：能调节模型参数、Context 策略与工具暴露方式
- 不过度绑架：不强制你采用某一种架构模式
- 透明：调用链路、上下文与中间状态可观测、可 debug

长远看，Agent 的能力上限，等于 Context Engineering 的上限。模型会持续变强、变便宜，但真正拉开团队差距的，是谁先学会在自己的场景里，设计稳定、可扩展、可迭代的信息流与工具体系