2026-10-24 12:36:32 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

上下文工程：AI 智能体从\"能聊\"到\"能扛事\"的关键一跃

原创

渊渟鹤峙
渊渟鹤峙

AI+网络安全笔记

2026年10月16日 18:45
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

过去一年，\"提示工程\"（Prompt Engineering）几乎成了 AI 应用开发的代名词——大家研究怎么措辞、怎么给例子、怎么让模型听懂人话。但当你真正尝试构建一个能连续工作几小时、跨多轮对话的智能体时，会发现一个残酷的事实：光会写提示词，远远不够。

想象一下：你让 AI 帮你重构一个有 50 个文件的代码库，任务要持续好几天。它得记住之前发现了什么问题、哪些已经解决、下一步该干什么——可每次对话，模型的\"注意力\"就那么多，塞进去的信息一多，它反而开始\"走神\"，答非所问。

这就是本章要解决的核心问题。内容来自 Datawhale 开源框架 Hello-Agents 第九章《上下文工程》，我会把原理讲透，同时保留几段关键代码，让你既能理解思路，也能上手实践。

一、从提示工程到上下文工程

先说一个正在发生的变化：在前沿模型厂商眼中，上下文工程是提示工程的自然演进。

所谓\"上下文\"，指的是每次调用大模型时，实际喂给它的那一整组 tokens。提示工程关心的是\"怎么写好一句指令\"，而上下文工程关心的是一个更宏观的问题：

什么样的上下文配置，最有可能让模型产出我们期望的行为？

图 9.1 提示工程 vs 上下文工程

两者的区别，看图就懂。提示工程聚焦于指令本身的写法和结构；上下文工程则是在推理阶段，\\策划并维护一个\"最优的信息集合\"\\——这个集合里不只有提示词，还包括系统指令、工具定义、外部数据、历史消息等一切会进入上下文窗口的东西。

为什么会发生这种转变？因为智能体变了。早期的 AI 应用大多是\"单轮问答\"——分类一下、生成一段文字，精调提示词就够了。但现在的智能体要在更长的时间跨度、跨多轮推理中持续工作。一个循环运行的智能体会不断产生新数据，这些信息必须被周期性地提炼。

于是，上下文工程的核心难题浮现了：从一个持续膨胀的\"候选信息宇宙\"里，甄别出哪些内容真正值得塞进那个有限的上下文窗口。

二、为什么上下文工程如此重要

你可能会问：现在模型的上下文窗口不是越来越大了吗？128K、200K 甚至更长，直接把信息全塞进去不就行了？

答案是：不行。 研究者发现了一个叫\"上下文腐蚀\"（context rot）的现象——随着上下文窗口里的 tokens 增多，模型从中准确回忆信息的能力反而下降。

这个现象几乎在所有模型上都会出现，只是退化曲线的陡峭程度不同。它的根源在于 Transformer 的架构约束：每个 token 理论上要和上下文里所有其他 token 建立关联，形成 n² 级别的注意力关系。上下文越长，模型的注意力就被\"摊得越薄\"。加上训练数据里短序列远比长序列常见，模型处理\"超长上下文\"的经验本就不足。

上下文必须被视作一种有限资源，而且具有边际收益递减。就像人的工作记忆有容量上限，LLM 也有一笔\"注意力预算\"——每多一个 token，都在消耗这笔预算。

好消息是，这种退化是\"性能梯度\"而非\"悬崖式崩溃\"：长上下文下模型依然强大，只是在信息检索和长程推理上精度会打折。所以，有意识的上下文工程，成了构建强健智能体的必需品。

2.1 好上下文的\"解剖学\"

在有限的注意力预算下，上下文工程的目标可以概括成一句话：用尽可能少、但信号密度尽可能高的 tokens，最大化拿到期望结果的概率。

具体到实践，有三个关键组件值得精心打磨：

系统提示（System Prompt）要清晰直白，信息层级\"刚刚好\"。常见的两个极端都要避免：一是过度硬编码，在提示里写一堆脆弱的 if-else 逻辑，难维护；二是过于空泛，只给宏观目标却缺少具体信号。建议用 XML 或 Markdown 分区组织（如 <background_information>、<instructions>），追求的是\"能完整勾勒期望行为的最小必要信息集\"——注意，\\\"最小\"不等于\"最短\"\\。

工具（Tools）定义了智能体与信息、行动空间的契约。好的工具应该职责单一、边界清晰、对错误鲁棒。最常见的失败模式是\"臃肿工具集\"——功能重叠模糊，连\"该用哪个工具\"都说不清。这里有句很扎心的话：

如果连人类工程师都说不准该用哪个工具，就别指望智能体能做得更好。

示例（Few-shot）始终值得提供，但别把所有边界条件一股脑塞进去。精选一组多样且典型的示例，直接\"画像\"出期望行为——对 LLM 而言，好示例胜过千言万语。

图 2 校准系统提示：在\"过度硬编码\"与\"过于空泛\"之间找到平衡

总的指导思想就四个字：信息充分但紧致。

三、智能体式搜索与长时程任务

先记住一个简洁的定义：智能体 = 在循环中自主调用工具的 LLM。 随着底层模型能力增强，智能体的自治水平也能水涨船高——更能独立探索复杂问题，并从错误中恢复。

3.1 从\"提前加载\"到\"用时再取\"

工程实践正在发生一个重要转变：从\"推理前一次性检索\"，过渡到\"及时上下文\"（Just-in-time, JIT）。

传统做法是预先把所有可能相关的数据一股脑加载进来。而 JIT 的思路恰恰相反——不预加载数据，只维护轻量的\"引用\"（文件路径、查询语句、URL），等真正需要时，再通过工具动态加载。这样模型可以自己撰写针对性查询、缓存必要结果，用 head/tail 之类的命令分析大体量数据，而不必把整块内容塞进上下文。

这其实更接近人类的认知方式：我们不会死记硬背所有信息，而是用文件系统、书签、收件箱这些\"外部索引\"按需提取。

更妙的是，引用的元数据本身也在传递信息。比如 tests/test_utils.py 和 src/core/test_utils.py，光看路径就能猜出用途差异。这种\"渐进式披露\"（progressive disclosure）让智能体能一层层构建理解：文件大小暗示复杂度、命名暗示用途、时间戳暗示相关性，每一步交互产生的新上下文，又反过来指导下一步决策。

当然，天下没有免费的午餐。运行时探索比预计算检索更慢，也需要更\"有主见\"的工程设计。缺乏引导时，智能体可能误用工具、钻牛角尖或错过关键信息。所以实践中混合策略往往更有效：先预加载少量高价值上下文保证速度，再放手让智能体按需探索。

3.2 长时程任务的三大策略

当任务长到超出上下文窗口——比如大型代码库迁移、跨数小时的研究——单纯增大窗口是治标不治本的。真正管用的是三招：

压缩整合（Compaction）：当对话接近上下文上限时，做一次高保真总结，再用这个摘要重启一个新窗口。压缩时要保留架构决策、未解决的缺陷、关键实现细节，丢弃重复的工具输出和噪声。调参口诀是\"先保召回，再提精度\"——先确保关键信息不丢，再剔除冗余。

结构化笔记（Structured note-taking）：也叫\"智能体记忆\"。让智能体定期把关键信息写到上下文之外的持久化存储里，需要时再拉回来。维护一份 TODO 列表、一个 NOTES.md，就能以极低的上下文开销，跨几十次工具调用保持进度一致。

子代理架构（Sub-agent）：主代理负责高层规划和综合，多个专长子代理各自在\"干净的上下文窗口\"里深挖，最后只回传一份凝练摘要（通常 1000–2000 tokens）。庞杂的搜索过程留在子代理内部，主代理专注整合——这就是\"关注点分离\"。

三招怎么选？需要长对话连续性用\"压缩整合\"，有阶段性成果的迭代任务用\"结构化笔记\"，需要并行探索的复杂研究用\"子代理\"。

理论讲完，下面看看 Hello-Agents 是怎么把这些理念落地成代码的。本章新增了三个组件：上下文构建器 ContextBuilder、笔记工具 NoteTool、终端工具 TerminalTool。

四、ContextBuilder：上下文的\"总装车间\"

ContextBuilder 的设计理念是\"简单高效\"——去除不必要的复杂性，统一用\"相关性 + 新近性\"的分数来做选择。它把上下文构建抽象成一条 GSSC 流水线：获取（Gather）→ 选择（Select）→ 结构化（Structure）→ 压缩（Compress）。

4.1 两个核心数据结构

流水线里流动的信息单元叫 ContextPacket（候选信息包），每条信息都被封装成它：

@dataclass
class ContextPacket:
    content: str              # 信息内容
    timestamp: datetime       # 时间戳
    token_count: int          # Token 数量
    relevance_score: float = 0.5   # 相关性分数(0.0-1.0)
    metadata: Optional[Dict] = None

而 ContextConfig 则统一管理所有可调参数。这里有个细节值得注意——reserve_ratio 参数专门为系统指令预留空间，确保关键信息不会被其他内容挤占：

@dataclass
class ContextConfig:
    max_tokens: int = 3000          # 最大 token 预算
    reserve_ratio: float = 0.2      # 为系统指令预留的比例
    min_relevance: float = 0.1      # 最低相关性阈值
    enable_compression: bool = True # 是否启用压缩
    recency_weight: float = 0.3     # 新近性权重
    relevance_weight: float = 0.7   # 相关性权重

4.2 GSSC 四阶段

Gather（汇集）：从多个来源收集候选信息——系统指令、记忆系统、RAG 知识库、对话历史、自定义信息包。这里最重要的设计是容错：每个外部数据源都用 try-except 包裹，单个源挂了不影响整体流程。系统指令被标记为最高优先级（relevance_score=1.0），永远保留。

Select（选择）：这是整条流水线的核心。它给每个信息包算一个综合分数，然后贪心地从高到低填充，直到用尽 token 预算：

# 综合分数 = 相关性权重 × 相关性 + 新近性权重 × 新近性
combined_score = (
    self.config.relevance_weight * packet.relevance_score +
    self.config.recency_weight * recency
)

其中相关性用 Jaccard 相似度计算（生产环境可替换为向量相似度），新近性用指数衰减模型——24 小时内保持高分，之后逐渐衰减。低于 min_relevance 阈值的信息会被直接过滤掉。

Structure（结构化）：把选中的信息组织成固定骨架的分区模板。这一步是 ContextBuilder 的点睛之笔——它输出一个稳定、可调试、可 A/B 测试的结构：

[Role & Policies]  # Agent 的角色定位和行为准则
[Task]             # 当前要完成的具体任务
[Evidence]         # 从知识库检索的证据
[Context]          # 历史对话和相关记忆
[Output]           # 期望的输出格式

Compress（压缩）：兜底机制。如果最终上下文仍然超限，就按分区逐个保留，实在放不下时截断，并标注\"[... 内容已压缩 ...]\"。关键是保持结构完整性，即使预算紧张，也要尽量留住每个分区的关键信息。

4.3 看看实际输出长什么样

用一个\"Python 数据工程顾问\"的例子，构建出的上下文是这样的：

[Role & Policies]
你是一位资深的Python数据工程顾问。你的回答需要:1) 提供具体可行的建议
2) 解释技术原理 3) 给出代码示例

[Task]
如何优化Pandas的内存占用?

[Evidence]
Pandas内存优化的核心策略包括:
1. 使用合适的数据类型(如category代替object)
2. 分块读取大文件
---
数据类型优化可以显著减少内存占用。例如,将int64降级为int32可节省50%内存。

[Context]
user: 我正在开发一个数据分析工具
user: 我打算使用Python和Pandas,已经完成了CSV读取模块
记忆: 用户正在开发数据分析工具,使用Python和Pandas

[Output]
请基于以上信息,提供准确、有据的回答。

角色、任务、证据、背景、输出要求，一目了然。把这样的上下文喂给 LLM，它想答偏都难。最后，ContextBuilder 可以无缝集成进 Agent，成为它的\"上下文管理大脑\"，自动完成信息的收集、筛选和组织。

五、NoteTool：给智能体一个\"笔记本\"

第八章的 MemoryTool 擅长管理对话式记忆，但对于需要长期追踪、结构化管理的项目式任务，我们需要一种更轻量、更\"人类友好\"的记录方式。这就是 NoteTool。

它的载体是 Markdown 文件，头部用 YAML 记录元数据，正文记录状态、结论、阻塞项和行动计划：

---
id: note_20250119_153000_0
title: 项目进展 - 第一阶段
type: task_state
tags: [refactoring, phase1, backend]
updated_at: 2025-01-19T15:30:00
---

# 项目进展 - 第一阶段

## 完成情况
已完成数据模型层的重构，测试覆盖率达到85%。

## 下一步计划
1. 重构业务逻辑层
2. 解决依赖冲突问题

这个设计的好处很实在：YAML 元数据机器可解析、支持精确检索；Markdown 正文人类可读、可手动编辑；纯文本格式天然对 Git 版本控制友好，几乎零额外开销。

NoteTool 支持七种笔记类型来组织信息，其中 blocker（阻塞问题）优先级最高：task_state（阶段进展）、conclusion（关键结论）、blocker（阻塞项）、action（下一步行动）、reference（参考资料）。它提供 create、read、update、search、list、summary、delete 七个操作，覆盖笔记的完整生命周期。

NoteTool 真正的威力在于和 ContextBuilder 的配合：每轮对话前，Agent 先检索相关笔记，转换成 ContextPacket 注入上下文。这样智能体就能\"记起\"几天前的进展，给出连贯的建议——这正是长时程任务保持连续性的关键。

六、TerminalTool：让智能体安全地\"动手\"探索

前面说的 JIT 上下文理念，靠什么落地？答案是 TerminalTool——它给智能体提供了安全的命令行执行能力，让它能即时查看日志、探索代码库、预览数据文件，而不必预先索引整个项目。

对比一下就明白它的价值：

# 传统方式:预先索引所有文件(成本高、易过时)
rag_tool.add_document(\"./project/**/*.py\")

# TerminalTool 方式:即时探索(快速、实时)
terminal.run({\"command\": \"find . -name '*.py' -type f\"})
terminal.run({\"command\": \"grep -r 'class UserService' .\"})
terminal.run({\"command\": \"head -n 50 src/services/user.py\"})

但让 AI 执行命令是件\"强大又危险\"的事。TerminalTool 用四层安全机制守住底线：

第一层，命令白名单——只允许 ls、cat、grep、find、head 这类只读命令，任何可能修改系统的操作一律拒绝。你想 rm -rf /？门都没有。

第二层，工作目录沙箱——只能访问指定目录及其子目录，cat /etc/passwd 或用 .. 逃逸都会被拦截。

第三层，超时控制——每个命令有执行时间上限，防止死循环或资源耗尽。

第四层，输出大小限制——防止一个 cat huge_file.log 把内存撑爆，超限自动截断。

给 AI 能力的同时，更要给它套上缰绳。这四层机制的克制，恰恰是生产级智能体和\"玩具 Demo\"的分水岭。

七、实战：把三件套拧成一个\"代码库维护助手\"

最后，把 ContextBuilder、NoteTool、TerminalTool 整合起来，就能构建一个真正的长程智能体——代码库维护助手。它能探索理解代码结构、记录发现的问题、追踪长期重构任务，并在上下文窗口的限制下保持连贯。

图 3 代码库维护助手的三层架构

它面对的正是长程任务的三大典型挑战，而每个挑战都有对应的解法：信息量超出窗口——用 TerminalTool 按需探索，只在需要时看具体文件；跨会话状态管理——用 NoteTool 记录阶段进展和关键决策；上下文质量与相关性——用 ContextBuilder 智能筛选，保证高信号密度。

来看它实际跑起来的样子。第一天让它探索代码库，它扫描后报告：\"这是一个 Flask 应用，约 3500 行代码，包含 models/routes/services 等模块\"，还顺手发现了 User.email 缺少唯一约束——自动记成一条 blocker 笔记。

第二天做质量分析，它查出代码重复、嵌套过深、测试覆盖率仅 45%，同样自动归档。到了第三天规划任务时，它能综合前两天的所有发现，按优先级排出重构清单：

🔴 高优先级(本周):
1. [blocker] User.email 添加唯一约束 — 风险低，1小时
2. [blocker] 提取 BaseService 减少重复 — 风险中，半天
3. [blocker] 重构 process_order 方法 — 风险高，1天
🟡 中优先级(下周): 补单元测试、清理 TODO

一周后回来检查，完整的笔记历史和会话报告都还在。这种跨天、跨会话的连贯性，正是上下文工程要解决的核心痛点——第一天发现的问题，第二天分析时被自动纳入，第三天规划时能综合所有发现。

这套基础框架还能继续生长：接入 RAGTool 做语义检索、拆成\"探索者/分析者/规划者\"多个子代理协作、集成测试工具自动验证重构结果，或者用 Gradio 搭个可视化界面。