随着大型语言模型（LLM）的能力日益强大，它们正越来越多地被用作复杂智能系统（即 “Agent”）的核心大脑。从能够自主编码的 AI 程序员到执行多步骤推理任务的框架，这些 Agent 的智能涌现，很大程度上源于其精心设计的“上下文（Context）”。然而，这个至关重要的“上下文工程”（Context Engineering）过程，长期以来却像一门难以言传的“手艺”，缺乏一套标准的描述和沟通语言。

ArXiv URL：http://arxiv.org/abs/2605.01920v1

开发者们通常只能依赖非正式的文字描述、临时绘制的图表，甚至是直接深入代码，才能理解一个 Agent 的上下文是如何构建和演变的。这种现状导致了诸多问题：我们很难精确比较不同论文中 Agent 实现的细微差别，难以复现他人的工作，甚至在团队内部沟通一个 Agent 的行为逻辑时，也常常充满歧义。一个看似微不足道的改动——比如在历史记录中是否包含模型的“思考”过程——就可能导致 Agent 性能出现显著差异。

为了解决这一困境，来自艾伦人工智能研究所（Allen Institute for Artificial Intelligence）等机构的研究者们，提出了一种名为“智能体上下文描述语言”（Agentic Context Description Language, ACDL）的解决方案。 ACDL 是一种专门用于精确、可读、标准化地描述和可视化 LLM 输入上下文结构及其动态变化的语言。它不像是一种编程语言，而更像是一套为 AI Agent 设计的“建筑蓝图”或“UML 图”，旨在将 Agent 上下文的设计从一门“玄学”手艺，推向一门严谨的工程学科。

什么是 ACDL？不止于 Prompt 的“结构图纸”

要理解 ACDL 的价值，首先要明确它所关注的核心问题：在 Agent 与 LLM 的多轮交互中，每一次提供给 LLM 的完整输入（即上下文）是如何被动态构建的。这个上下文不仅包含用户的最新指令，还可能包括系统设定、历史对话、工具调用的结果、模型的中间推理步骤等。ACDL 的目标，就是用一种形式化的语言，清晰地描绘出这个复杂输入的“配方”和“演变规则”。

ACDL 的核心思想是抽象化。它不关心上下文中具体句子的措辞，而是关注每个信息块的角色、类型和来源。例如，它会明确区分一段内容是来自“系统指令”（system instruction）、“用户查询”（user query），还是“工具输出”（tool output）。

更重要的是，ACDL 引入了几个关键构造，以捕捉上下文的动态特性：

• 时间索引：通过 $t` 这样的标记，ACDL 可以精确引用过去某个交互步骤中的元素。例如，可以指定在当前步骤 $t$ 的上下文中，需要包含第 $t-1$ 步模型的思考过程。

• 控制流：ACDL 支持使用循环（loops）和条件（conditionals）等结构，来描述上下文的构建逻辑。这对于实现像 ReAct（推理与行动）这样包含迭代循环的 Agent 框架至关重要。

• 结构化引用：语言允许描述如何从过去的回应或文档中提取结构化内容，例如，只引用第 $i$ 个文档的来源 $docs[i].source`。

ACDL 的强大之处在于其可视化能力。一段 ACDL 描述可以被自动渲染成清晰的图表，让复杂的上下文结构一目了然。下图展示了三种相似但有细微差异的 ReAct 循环实现，通过 ACDL 的可视化，这些差异变得清晰可见：

在上图中，我们可以清晰地看到一个基础 ReAct 循环的结构：它由系统指令（System）、用户问题（User）以及一个包含“思考-行动-观察”的循环体构成。而论文中提到的变体，则可能在结构上有所不同：一个版本可能在历史记录中省略了“思考”（thought）部分，另一个版本则可能将工具（tools）的定义放在上下文的末尾而非开头。这些在代码或文字描述中容易被忽略的细节，在 ACDL 图中暴露无遗，而实验证明，这些细微的结构差异确实会导致 Agent 性能的可衡量变化。

ACDL 实战：从简单循环到复杂的“宝可梦大师”

ACDL 的表达能力远不止于简单的 ReAct 循环，它可以扩展到描述当今最先进、最复杂的 Agent 系统。研究者们通过几个实例，展示了 ACDL 作为文档和分析工具的强大能力。

逆向工程开源 Agent

团队通过深入研究代码和追踪运行轨迹，为两个流行的开源编码 Agent——OpenCode 和 OpenClaw 编写了 ACDL 描述。这项工作本身就凸显了当前 Agent 设计缺乏清晰文档的痛点。通过 ACDL，这些复杂系统的核心上下文逻辑被清晰地呈现出来，极大地降低了理解和学习这些系统的门槛。

上图展示了 OpenCode Agent 的上下文结构，我们可以看到其中包含了任务定义、文件列表、过去的交互历史以及一个用于代码生成的特定格式区域。这种“蓝图”对于任何想要复现或改进该 Agent 的研究者来说，都是一份极其宝贵的文档。

记录顶尖系统的设计：以 Gemini 玩宝可梦为例

一个更具说服力的例子，是为 Google Gemini 团队发布的“宝可梦蓝”技术报告中的 Agent 进行文档化。这个 Agent 完成了在《宝可梦蓝》游戏中进行游戏并取得胜利的复杂任务，其决策过程涉及长短期记忆、复杂的环境观察和多步规划。ACDL 成功地将这个复杂 Agent 的上下文结构进行了可视化，证明了其处理真实世界顶尖系统的能力。

这张图清晰地展示了 Agent 在每个决策点所“看到”的信息全景，包括游戏截图、过去的行动与反思、当前任务等。这不仅是一份技术文档，更是一种设计思想的沉淀，使得其他研究者可以站在巨人的肩膀上，思考如何构建下一代的游戏 AI 或更通用的 Agent。

超越人类沟通：成为人与 AI 协作的桥梁？

ACDL 的价值不仅在于促进人与人之间的清晰沟通。研究者们发现，它还具备成为“人机交互”新媒介的潜力。

为了推动 ACDL 的普及，团队提供了一整套开源工具，包括一个网页版的编辑器和可视化工具、一个 VS Code 插件（支持语法高亮和实时渲染），以及一份为 Claude Code Agent 编写的技能文件。这些工具大大降低了使用 ACDL 的门槛。

一个有趣的发现是，像 Claude Code 这样的代码生成模型，能够“阅读”并理解 ACDL 规范。研究者们在实验中观察到，他们可以给模型一段 ACDL 描述，让它生成相应的 Agent 循环代码，甚至可以将一个 Agent 的实现从一种结构（由 ACDL 描述）转换为另一种结构。这预示了一个激动人心的未来：开发者或许不再需要手动编写所有 Agent 的底层逻辑代码，而是可以在更高的抽象层次上，通过 ACDL 来“设计”Agent 的行为，然后让 AI 助手来完成具体的代码实现。

局限性与未来展望

作为一项开创性的工作，ACDL 并非没有局限。目前，它主要适用于那些在构建每个上下文步骤之间状态固定的 Agent 系统。对于那些在单次上下文构建过程中，状态会发生动态变化的复杂系统，用 ACDL 进行描述会比较繁琐。研究者们计划在未来的版本中解决这些问题。

尽管如此，ACDL 的提出无疑是 Agent 工程化领域迈出的重要一步。在“上下文工程”正在取代“提示工程”成为构建高级 AI 系统核心的时代，我们迫切需要标准化的工具来管理复杂性。 ACDL 通过提供一种精确、可视化且独立于具体实现的描述语言，为整个领域提供了一套共享的词汇和设计蓝图。

它让比较不同 Agent 的“内在思想”成为可能，让复现研究成果变得更加可靠，也让团队协作的效率得以提升。从长远来看，ACDL 这类语言的出现和普及，将推动 AI Agent 的开发从依赖个人技巧的“手工作坊”模式，向着更加规范、严谨和可扩展的“工业化生产”模式演进。