ai

如何在没有无尽脚本的情况下处理不断增长的 AI 上下文

发布: (2026年2月5日 GMT+8 01:18)
8 min read
原文: Dev.to

Source: Dev.to

学习 Acontext 如何将上下文工程从数天的手动工作简化到仅几小时，以及为何上下文‑数据平台对生产代理至关重要

Image6-1

在构建 AI 代理时，真正的复杂性来源很少是模型本身。关键在于它的 上下文。

模型能力迅速提升，但任何构建过生产级代理的人都知道一个模式：系统运行时间越长、处理工具越多或跨多轮对话，繁重的工作就会从提示设计转移到 上下文工程。

为什么上下文工程会成为真正的瓶颈？

在实际操作中，上下文工程 并不是一个抽象概念。它是一系列非常具体的工程任务：

  • 存储文本、图像、记忆、工件、工具调用…
  • 管理随时间无限增长的会话
  • 在 OpenAI、Anthropic 和 Gemini 之间切换消息格式
  • 在不破坏语义的前提下截断或过滤上下文
  • 回答：“LLM 当时到底看到了什么？”

这些任务具有以下几个共同特征：

  • 几乎所有生产环境的代理都会遇到它们；
  • 它们是持续性的成本，而非一次性工作；
  • 往往以临时脚本和胶水代码的形式实现。

因此，团队往往花费更多时间维护上下文逻辑，而不是提升代理的实际推理或行为。

更简洁的模式：将上下文数据视为统一层

问题不在于上下文工程本身固有复杂，而在于它通常位于错误的位置。

一种更具启发性的思维模型是将上下文视为 系统层面的数据关注点，而不是 提示逻辑。

该模型包含三个核心理念：

  1. 原始消息和产物完整保存——在会话演进过程中绝不重写或修改。
  2. 编辑在读取时进行，而不是通过变更已存数据——截断、过滤和 token 控制在检索阶段完成，原始会话保持不变。开发者可以使用明确的上下文窗口指标来决定是否需要编辑。
  3. 声明式规则取代分散的脚本——开发者不再在业务逻辑中散布启发式代码，而是使用声明式策略描述上下文应如何被塑造。

有了这种转变，上下文工程就变得可预测、可复用，而不再脆弱且只能定制。

Acontext 用两个 API 简化上下文工程

从这个角度看，“几行代码” 并不 意味着工作量更少。它意味着 将复杂性转移到系统层，在那里可以实现一致的处理。

Acontext 提供了两个简单的 API：store_message() 和 get_messages()。

  • 原始上下文只存储一次。
  • 只有在检索消息时才会进行上下文编辑。
  • 编辑行为通过显式策略来定义。
  • 相同的规则适用于所有代理和会话。

实际代码演示：即时上下文编辑

下面的示例展示了如何将上下文编辑从应用逻辑迁移到声明式读取步骤。与其在代码中自行拉取消息、统计 token、裁剪历史并重建模型输入，应用只需一次性描述其编辑规则并将其传递给 get_messages。Acontext 会一致地应用这些规则，并返回会话的编辑视图。

因为 编辑发生在读取时，更改上下文行为无需重写存储逻辑或重新处理历史数据。你可以调整策略、比较不同视图，或在多个代理之间复用同一套规则，而无需复制代码。

编辑策略（开箱即用）

StrategyDescription（描述）Benefit（收益）
get_token_counts()在编辑前检查会话当前的 token 大小。上下文编辑变为基于数据而非基于启发式。
token_limit通过删除最早的消息，直到总 token 数在指定限制内，从而截断会话。工具调用和工具结果对会被正确保留。无需自定义截断逻辑，避免工具历史被破坏。
remove_tool_result用占位符替换较旧的工具结果内容，同时保留最近的结果。大量冗长的工具输出不再占用上下文，同时不丢失执行结构。
remove_tool_call_params删除较旧工具调用的参数，只保留 ID 和名称，以便工具结果仍能引用它们。减少 token 使用，同时保留工具调用与结果之间的因果关联。
middle_out……
offload_to_log……
remove_by_completed_tasks……
from acontext import AcontextClient

client = AcontextClient(
    base_url="http://localhost:8029/api/v1",
    api_key="sk-ac-your-root-api-bearer-token"
)

# Get the session with editing strategies applied
edited_session = client.sessions.get_messages(
    session_id="session-uuid",
    edit_strategies=[
        {"type": "token_limit", "params": {"limit_tokens": 20_000}},
        {"type": "remove_tool_result", "params": {"keep_recent_n_tool_result": 3}},
        # ... add more strategies as needed ...
    ],
)

# Retrieve the original, unedited session
original_session = client.sessions.get_messages(
    session_id="session-uuid"
)

在实际使用中，这可以减少开发者需要维护的胶水代码量，缩短调优上下文行为的迭代周期，并使上下文工程 可预测、可复用且平台无关。

为什么上下文数据平台对生产代理很重要

这种统一的数据层抽象并不是为了让 AI 代理在演示中看起来更好，而是为了让它们在真实的生产环境中可靠地运行，在这些环境中上下文会增长，工具会重复运行，且故障代价高昂。

在实践中，团队开始看到明确、具体的改进：

  • 长期任务因上下文增长得到安全且一致的处理而更少出现失败。
  • 代理的行为在不同运行、环境以及模型升级之间变得可预测且可复现。
  • 调试不再依赖于猜测模型在特定时刻可能看到的内容。
  • 上下文工程退居幕后，被视为基础设施而非应用逻辑。

前进之路

Context engineering does not have to take days of manual work.

With Acontext, tasks that once required days of custom wiring can be done in hours—safely, consistently, and without rewriting the same glue code.

That is what simplifying context engineering means in practice.

If this aligns with how you build agents, please try Acontext in a real workflow:

  • Share what works, what breaks, and what you wish existed.
  • Join the community, give feedback, and help agent builders shape the open‑source roadmap.

链接

  • GitHub:
  • Discord:
Back to Blog

相关文章

阅读更多 »