ARTICLE / AI Agent · Context Engineering

Agent Context 应该如何设计？从 Stable Prefix 到 Dynamic Trajectory

Context 不是聊天记录，而是模型这一轮能看到的全部工作环境。本文给出 Context = Stable Prefix + Dynamic Trajectory + Current State 的结构，讲清为什么 System Prompt 与 Tool Definitions 要尽量稳定、为什么当前时间不该写进 System Prompt，以及为什么目标不是 Maximum Context 而是 Maximum Relevant Context。

发布: 2026年9月3日
阅读: 约 5 分钟
作者: Nicolas Leigh

READS0次阅读

上一篇我们提到，一个现代 AI Agent 可以简单理解为：

Agent = Model + Harness

Model 提供推理和决策能力，而 Harness 负责工具调用、状态管理、执行循环，以及最重要的 Context Management。

但这里马上会出现一个问题：

既然 Context 如此重要，那么一个 Agent 的 Context 到底应该怎么组织？

最简单的答案是：

稳定的信息放前面，动态的信息不断向后追加。

这可以进一步概括成：

Context = Stable Prefix + Dynamic Trajectory

理解这个结构，是理解现代 Agent Context Engineering 的第一步。

Context 不只是聊天记录

很多人第一次开发 Agent 时，会把 Context 简单理解成 messages = [user, assistant, user, assistant, ...]。这对于普通 Chatbot 也许够用，但对于 Agent 来说远远不够。

一个真正执行任务的 Agent，模型每次推理时可能需要同时看到的内容包括：System Prompt、Tool Definitions、User Request、Assistant Messages、Tool Calls、Tool Results、Current State、Environment Information 等。

比如 Coding Agent 在修改一个项目时，不仅需要知道用户说了什么，还需要知道：

当前有哪些工具？
刚刚读取了哪些文件？
执行测试的结果是什么？
已经完成了哪些步骤？
当前工作目录在哪里？

这些信息共同构成了模型当前的"世界"。

所以 Context 并不是简单的 Conversation History。它更接近模型在这一轮做决策时能够看到的全部工作环境。

Stable Prefix：尽量保持稳定的上下文

Context 的第一部分可以称为 Stable Prefix——也就是相对稳定、不会随着每轮任务频繁变化的信息。最典型的就是 System Prompt 和 Tool Definitions。

System Prompt 负责定义 Agent 的基本行为，例如：

你是一名 Coding Agent。

修改代码前先阅读相关文件。
不要修改与当前任务无关的代码。
修改完成后执行测试。

Tool Definitions 则告诉模型你能做什么，例如：

read_file(path)
write_file(path, content)
search_code(query)
run_shell(command)

这些内容通常在一次 Agent Session 中不会频繁变化，因此非常适合放在 Context 最前面。

可以把它理解为一个员工入职时收到的工作手册 + 工具说明书。只要岗位职责没有变化，就没有必要每完成一步任务重新修改它。

Dynamic Trajectory：Agent 真正的工作轨迹

Stable Prefix 后面，则是不断增长的 Dynamic Trajectory——也就是 Agent 执行任务过程中产生的轨迹。例如：

User:
修复登录接口的并发问题。

Assistant:
我先检查登录相关代码。

Tool Call:
search_code("login")

Tool Result:
internal/service/login.go
internal/repository/user.go

Assistant:
读取 login.go。

Tool Call:
read_file("internal/service/login.go")

Tool Result:
...

随着任务继续，Trajectory 会不断增长：User → Assistant → Tool Call → Tool Result → Assistant → Tool Call → Tool Result → ...

这条轨迹非常重要，因为它记录了 Agent 已经知道什么，以及 Agent 已经做过什么。

如果这些信息丢失，模型可能重新搜索同一个文件、重复执行失败方案，甚至忘记之前已经做出的决定。

为什么 Tool Result 也是 Context？

这一点很容易被忽略。

模型可以决定调用 read_file("config.go")，但是模型本身并不会真的读取文件。

Harness 执行工具以后，会获得结果：

Tool Result:
type Config struct {
    DBHost string
    DBPort int
}

下一轮调用模型时，Harness 必须把这个 Tool Result 放回 Context，模型才能知道"原来这个文件里面是这些内容"。

因此完整过程其实是：

Model
  ↓
Tool Call
  ↓
Harness
  ↓
Environment
  ↓
Tool Result
  ↓
Context
  ↓
Model

模型通过 Tool Call 影响外部世界，又通过 Tool Result 重新观察外部世界。从这个角度看，Agent 本质上是在不断进行 Observe → Think → Act → Observe → Think → Act 的循环，而 Context 就是承载这些 Observation 的地方。

动态状态应该尽量放在后面

除了历史轨迹，Agent 还经常需要一些非常动态的信息，例如当前时间、当前目录、剩余 Token、当前 TODO、工具调用次数、最近一次错误、任务完成进度。

这些信息有一个共同特点：它们几乎每轮都会变化。

因此一个比较合理的 Context 结构是：

System Prompt
Tool Definitions
────────────────
User Request
Assistant Messages
Tool Calls
Tool Results
────────────────
Current State

也就是越稳定的信息越靠前，越动态的信息越靠后。不要反过来。

例如，不要把当前时间直接写进 System Prompt：

You are an AI Agent.

Current time:
2026-09-15 12:21:32

因为下一轮就可能变成 2026-09-15 12:21:40，这样 Context 最前面的内容也跟着变化。更合理的方法，是把时间作为运行状态放到 Context 后面：

<agent_status>
current_time: 2026-09-15 12:21
</agent_status>

这样 System Prompt 仍然可以保持稳定。

至于为什么"前面的内容保持稳定"不仅影响结构，还会显著影响 Agent 的成本和响应速度，就涉及一个非常重要的概念：KV Cache / Prompt Cache。这个问题下一篇单独讨论。

Context 的核心不是"越多越好"

设计 Context 时，还有一个很容易产生的误区：

既然模型需要信息，那就把所有信息都塞进去。

但 Context 并不是越大越好。

假设 Coding Agent 正在修复一个 Redis 并发问题。真正有价值的信息可能只有：用户需求、相关 Redis 代码、刚刚执行的测试结果、当前修改状态。

而整个项目可能有：前端代码、CI 配置、Docker 文件、几十份文档、几百个源码文件。如果全部塞进 Context，不仅浪费 Token，还会让真正重要的信息被大量无关内容淹没。

所以 Context Engineering 的目标并不是 Maximum Context，而应该是 Maximum Relevant Context——也就是在有限的 Token 预算里，让模型看到尽可能多的有效信息。

一个更合理的 Agent Context

综合前面的讨论，一个比较理想的 Agent Context 可以抽象成：

System Prompt       ← Stable Prefix
Tool Definitions    ← Stable Prefix
────────────────
User Request
Dynamic Trajectory:
  Assistant → Tool Call → Tool Result → ...
────────────────
Current Status      ← TODO / Env / Runtime

可以把它概括成三个原则：前面稳定，中间追加，后面动态。

这样的结构不仅更容易维护，也为后续很多 Agent 优化提供了基础，例如 Prompt Cache、Context Compression、Agent Status Bar、Skills、Memory、Sub-Agent 等，本质上都建立在这套 Context 结构之上。

结语

Context Engineering 并不是简单地把更多信息交给模型。

真正困难的问题是：什么信息应该出现在哪里？

对于 Agent 来说，一个非常实用的基本原则是：

Context = Stable Prefix + Dynamic Trajectory + Current State

System Prompt 和 Tool Definitions 尽量稳定；Agent 的工作过程按照 Trajectory 持续追加；当前时间、TODO、环境状态等高频变化的信息则放到后面。

这样模型每次"重新醒来"时，都能够快速回答三个问题：

我应该遵守什么规则？
我之前做了什么？
我现在应该做什么？

而这正是一个能够稳定执行长任务的 Agent 所需要的基础。

参考资料

《深入理解 AI Agent》第 02 章：上下文工程