Agent上下文工程解析：Monadic设计与RLM框架如何解决长上下文挑战

最近研读了两篇相关论文，分别是《Monadic Context Engineering》[1] 与《RECURSIVE LANGUAGE MODELS》[2]。结合去年开发量化分析 Multi-Agent 工具的经验，正好可以深入探讨一下 Agent 开发中的 Context Engineering。

这其实是一个相当棘手的问题。例如，模型输出错误可能导致调用不存在的工具，或者由于网络不稳定等外部因素，工具调用无法返回正确的结果。在去年 Kimi K2 发布之前，许多开源模型的 Agent 执行能力都存在各种问题。以之前构建的一个股票量化 Multi-Agent 系统为例，其中存在这样的工作流：

当一个资产组合中的标的数量增加后，经常因为中间某一步骤失败而导致整个任务失败。尤其是某些模型在处理大量资产时，容易出现函数名调用错误等问题。或者由于上下文过长，导致单次任务成本极高（例如使用 Claude 时可能超过 1 美元）。

因此，当时在上下文工程上做了一些优化，其思路与这两篇论文的内容不谋而合。

1. Monadic Context Engineering

1.1 为什么需要 Monad？

在介绍 MCP 时其实就触及了这个问题：MCP is a Monad。在函数式编程的视角下，它可以被理解为一个在上下文中解包值、应用函数、然后重新打包值的过程。

MCE 论文将这一思想拓展到了整个上下文工程领域，并阐述了当前主流方法的主要缺陷。

“命令式”指的是开发者需要明确编写每一步操作的执行顺序和控制流（例如，使用大量的 if/else 处理错误，手动传递状态对象）。“Ad hoc”则指这些解决方案通常是为特定问题定制的，缺乏通用、可复用的底层架构，导致代码难以维护和扩展。其后果是系统非常脆弱，稍有预期之外的输入（如 API 失败）就可能崩溃或进入不一致状态。

在 Agent 开发中，我们通常会面临几大核心挑战：

正如文章开头提到的场景，对于一个包含多个标的的资产组合，我们期望 Agent 能并行执行分析，以最短时间生成报告和交易决策，从而构建中频量化策略。然而，并行执行带来的上下文爆炸和复杂的错误处理是非常麻烦的事情。这也催生了从 MCE 视角进行转变的思路：不再将 Agent 的工作流视为一系列指令，而是看作一个“在上下文中进行的计算”。

这种思路提供了形式化基础，将状态、错误、并发等关注点定义为横切逻辑，并由 Monad 结构本身进行内在化管理，无需手动编写繁琐的样板代码。

1.2 基于 Monad 的 Agent 开发

当前 Agent 开发面临一系列反复出现的根本性挑战。

其中最重要的是维护状态的完整性，这要求在多步、可能失败的操作中可靠地传递信息。同时，Agent 需要错误恢复能力来优雅处理现实世界的失败（如 API 超时、模型输出格式错误），而不让核心逻辑被防御性代码淹没。此外，开发者需要逻辑的可组合性，以便像搭积木一样从独立单元构建复杂行为。

除了顺序逻辑，现代 Agent 还要求强大的并发性来编排多个同时发生的动作，避免陷入手动线程管理的泥潭。架构还应严格管理计算效应，区分纯逻辑计算与改变外部世界的副作用操作。最后，随着系统扩展，必须解决Agent 编排问题，管理可动态组队协作的专业 Agent 团队。

借鉴函数式编程的思想成为一个直接的解决方案。它为在上下文中组合计算提供了标准化方法。函子 (Functor) 允许你将纯函数应用到上下文中的值上。应用函子 (Applicative Functor) 扩展了此能力，支持将包装好的函数应用到包装好的值上，这对并发执行独立计算至关重要。最后，Monad 允许对存在依赖关系的操作进行排序，其中后续计算由前一个结果决定。

作者形象地解释了 bind 操作：它让我们能够为计算构建一条“铁路”。每个逻辑步骤都是一个车站，而 bind 则铺设轨道，确保计算在“成功轨道”上运行。如果任何步骤失败，bind 会自动将整个计算分流到“失败轨道”，绕过后续车站，直达终点。

2. AgentMonad 设计

本章探讨如何将 MCE 具体应用于构建健壮的 AI Agent。

2.1 Monad Transformer

单个 Agent 操作可能需要与外部 API 交互、处理可能的失败、并更新内部状态。试图用朴素嵌套类型（如 Task<Either<State<...>>>）来管理这些关注点是行不通的，它会迫使开发者手动解开每一层上下文，重新引入 Monad 旨在消除的深层嵌套回调。

Monad Transformer 是一种类型构造器，它接受一个现有的 Monad M，并产生一个新的、更强大的 Monad T(M)，结合了两者的行为。关键在于，Transformer 提供了一个 lift 操作，允许内部 Monad 中的计算无缝地在组合后的外部 Monad 上下文中执行，从而创建一个共享统一接口的能力栈。

AgentMonad 利用此技术创建了一个专为 人工智能 Agent 工作流设计的栈。

底层是 IO 或 Task Monad，负责管理与外部世界的交互，分离动作描述与执行。其上应用 EitherT Transformer，引入短路错误处理逻辑，这直接模拟了像 MCP 等规范的要求。最外层用 StateT Transformer 包装，用于状态管理。

最终得到的类型 StateT S (EitherT E IO) 确保了交互可观测、错误处理健壮、状态管理函数式，且工作流可组合。对这个复合结构的一次 bind 操作就能正确串联状态、检查错误并排序外部动作，这体现了良好的系统架构设计思想。

2.2 Level 1: AgentMonad 作为函子 (Functor)

最基础的操作涉及将纯函数应用到上下文中的值，而不改变上下文本身。这是函子及其 map 操作的角色。

map 函数接受一个函数 f: A -> B 和一个 AgentMonad[S, A]，返回一个 AgentMonad[S, B]。它将 f 应用于被包装的值，同时保持状态和成功/失败状态不变。如果流程已失败，map 不会执行任何操作。

2.3 Level 2: AgentMonad 作为应用函子 (Applicative Functor)

这用于处理更复杂的场景：如果要应用的函数本身也被包装在上下文中怎么办？这对于组合独立计算的结果特别有用。

apply 操作接受一个包含函数 (A -> B) 的 AgentMonad 和一个包含值 (A) 的 AgentMonad，返回一个包含结果 (B) 的新上下文。该机制从各自上下文中提取函数和值并应用，同时确保状态传播且失败被绕过。

2.4 Level 3: AgentMonad 作为 Monad

这解决了 Agent 编排的核心挑战：对操作进行排序，其中每个步骤的逻辑都依赖于前一个步骤的结果。

bind 操作接受一个 AgentMonad[S, A] 和一个函数 f: (S, A) -> AgentMonad[S, B]。该操作从第一个上下文中解包出值和状态，传递给 f，f 返回一个新的 AgentMonad。这允许每个步骤独立地改变状态或触发失败，而状态 S 由该结构隐式传递。

这种结构抽象掉了状态传递和错误检查的重复性样板代码，开发者可以专注于定义每个独立步骤的逻辑。其底层算法逻辑确保了流程的健壮性。

一个简单的使用示例如下：

task = "What is a Monad?"
initial_state = AgentState(task=task)

# 代理逻辑被定义为一条声明式、健壮的链
async_flow = (
    AsyncAgentMonad.start(initial_state)
    .then(lambda s, _: plan_action(s, task))
    .then(lambda s, call: execute_tool(s, call))
    .then(synthesize_answer)
    .then(format_output)
)
final_result_flow = await async_flow.run()

或者进行并行调用：

async def create_daily_briefing(state: AgentState, user_query: str) -> AgentMonad:
    # 1. 定义独立的异步任务
    news_task = AsyncAgentMonad.start(state, user_query).then(async_fetch_news)
    weather_task = AsyncAgentMonad.start(state, user_query).then(async_fetch_weather)
    stocks_task = AsyncAgentMonad.start(state, user_query).then(async_fetch_stocks)

    # 2. 通过 Applicative 的 ‘gather’ 并发执行
    # 结果是一个将解析为结果列表的 AsyncAgentMonad
    gathered_data_flow = AsyncAgentMonad.gather([news_task, weather_task, stocks_task])

    # 3. 合成收集的结果
    synthesis_step = await gathered_data_flow.then(async_synthesize_briefing).run()
    return synthesis_step

这类似于前端框架的演进：从 Express 的回调地狱，到 Koa2 的洋葱模型。而类似于 React/Redux 的偏函数式风格，将复杂状态处理前置，期待 Agent 框架也能出现此类更优雅的范式。

3. 沙箱 Monad

另一个值得深思的问题是：在模型训练和推理中，涉及沙箱执行环境（如浏览器/移动设备/计算机操作模拟）时，如何构建这些沙箱的状态记录与回滚机制，以进一步降低副作用的影响？例如，是否可以在 VM/容器级别利用快照，或为网页类应用前端适配此类 Monadic 状态管理？这是一个有待展开的议题。

4. RECURSIVE LANGUAGE MODELS

第二篇论文《Recursive Language Models》提出了一种新颖、强大且通用的推理框架，旨在解决大语言模型的长上下文处理瓶颈。通过将长提示外部化到 REPL 环境，并允许模型通过代码和递归调用与之交互，RLM 成功地将有效输入长度扩展了数个数量级，并在各种复杂度任务上显著优于现有方法。

其本质是构建了一个 REPL 环境，对长上下文的处理采用了分治与递归算法，实际上就是把 Context 当作一个栈来使用。去年在构建量化交易算法 Agent 时，也采用了类似逻辑，不过分治和递归都是手动编写的代码。

4.1 长上下文的问题

现有方法存在局限：

1. 上下文压缩/精简 (Context Condensation/Compaction)：当上下文超限时反复总结。根本缺陷在于这是有损的，假设早期细节可被安全遗忘。对于需要密集访问提示多部分的任务，表现不佳。
2. 任务分解 (Task Decomposition)：许多工作专注于递归分解任务，但其输入仍无法超越底层 LLM 的上下文窗口。

4.2 RLM 的观点

RLM 的核心观点是：长提示不应直接被送入神经网络，而应被视为 LLM 可进行符号化交互的外部环境。

其工作机制如下：

1. 给定任意长提示 P，RLM 初始化一个编程环境 REPL（论文中使用 Python REPL）。
2. P 被加载为 REPL 环境中的一个变量（例如，一个长字符串或字符串列表）。
3. RLM 向 LLM 提供关于 REPL 环境的元信息，并允许 LLM 编写代码来：
   • 窥视 (Peek into)：查看变量 P 的片段。
   • 分解 (Decompose)：将 P 切分成小块。
   • 递归调用 (Invoke itself recursively)：对 P 的片段构建子任务，并递归调用自身来处理。
4. 迭代与反馈：LLM 可以迭代观察代码执行副作用，并根据结果调整下一步行动。

4.3 Token as instruction

从体系结构视角看，通过 REPL 让大模型分治递归处理复杂任务，实质上是 Token as instruction。这赋予了大模型本身一种栈式结构，就像在构建一个能够产生并执行代码的通用计算机架构。大模型可能正从纯粹的自回归走向自生成指令的道路。

沿着这条路进行强化学习应该能获得一些收益，RLM 论文中展示的例子也印证了这一点。

从技术上看，结合基于块的稀疏注意力 (Block-based Sparse Attention) 会是一个非常有趣的视角。

参考资料

[1] Monadic Context Engineering: https://arxiv.org/pdf/2512.22431

[2] RECURSIVE LANGUAGE MODELS: https://arxiv.org/pdf/2512.24601

希望这篇关于 Agent 上下文工程的探讨能对你有所启发。欢迎在云栈社区交流更多关于 AI 与系统架构的思考。