CaveAgent让LLM学会了“跑代码”，你能把Agent变成Jupyter里的“老司机”

CaveAgent的核心思想很简单：与其让LLM费力地去“读”数据的文本快照，不如给它一个如果不手动重启、变量就永远“活着”的 Jupyter Kernel。

这项由香港科技大学（HKUST）领衔的研究，为我们展示了一种“Code as Action, State as Memory”的全新可能性。它解决了所有开发过复杂Agent的工程师最头疼的多轮对话中的“失忆”与“漂移”问题。

在传统的无状态交互中，每一轮对话都意味着上下文的重置与重建。而CaveAgent的这项工作证明了通过维护一个持久化的运行时环境（Runtime Stream），我们可以实现零序列化成本的状态流转。本文将带您深入其底层的运行时管理机制，看看它是如何在长达40轮的复杂任务中保持状态“不掉线”的。

为什么现在的Agent总是“记性不好”？

在深入CaveAgent之前，我们需要先聊聊目前主流Agent架构（如ReAct或基于JSON的Function Calling）的一个核心缺陷：文本化瓶颈（Textualization Bottleneck）。

JSON模式的死循环

目前的Agent工作流本质上是一个基于文本的序列化循环：

• 第1步：模型想看股票数据，输出一段JSON文本 {tool: "get_stock", args: "AAPL"}。
• 第2步：外部程序解析这个JSON，去调API，拿到数据。
• 第3步：（最要命的一步） 外部程序把拿到的一大坨数据（比如DataFrame）强制转成字符串文本。
• 第4步：这些文本被塞回模型的上下文窗口（Context Window），模型读取后继续生成下一轮文本。

这种模式带来的三个大坑

1. 上下文爆炸：如果您处理的是一个包含百万行数据的数据库，转成文本后，任何模型的上下文窗口都扛不住。
2. 结构丢失与幻觉：复杂的数据对象（如类实例、图结构）一旦被“压扁”成文本，就丢失了原有的属性和方法，模型很容易产生幻觉，编造不存在的参数。
3. 多轮对话中的遗忘：由于Agent是无状态的（Stateless），每一轮对话它都必须重新阅读之前的历史。随着对话变长，早期的关键信息很容易被挤出上下文，导致任务失败。

CaveAgent的解法：双流架构

研究者们并没有仅仅在Prompt上修修补补，而是彻底重构了Agent的交互逻辑。他们提出了CaveAgent，它的核心思想可以用一句话概括：将LLM从“文本生成器”转变为“运行时操作者”。其核心是一个双流架构（Dual-stream Context Architecture）。

这套架构将Agent的“思考”与“记忆”完全拆分开来：

1.语义流（Semantic Stream）：轻量级的大脑

• 职责：负责推理、意图理解和生成代码。
• 特点：它非常“克制”。它不接触庞大的原始数据。它看到的只是数据的“元数据”（Metadata），比如变量名、数据类型摘要、函数签名。
• 优势：无论处理多大的数据，语义流里的Token消耗都极低，保证了模型时刻保持清醒。

2.运行时流（Runtime Stream）：持久化的身体

• 职责：这是一个基于Python的持久化执行环境（类似于IPython内核）。
• 特点：这里存储着真正的Python对象。无论是Pandas DataFrame、机器学习模型，还是数据库连接，它们都以原生的形式“活”在内存里。
• 优势：数据不需要被序列化成文本，状态（State）在多轮对话中自动保持，就像您在Jupyter Notebook里定义的变量，下一行代码可以直接用。

核心技术拆解：它到底强在哪？

CaveAgent之所以能碾压传统方法，主要归功于以下三个技术创新：

变量与函数注入 (Variable and Function Injection)

在传统Agent中，如果您想让AI处理一个表格，您得把表格内容贴给它。但在CaveAgent中，研究者实现了真正的对象注入。

• 元数据提取：系统会自动提取对象的描述（例如：name: df, type: DataFrame, columns: [price, vol]）发给语义流（LLM）。
• 命名空间映射：真正的对象被直接映射到运行时流的全局命名空间中。
• 直接调用：LLM生成的代码可以直接调用这些对象的方法（如 df.plot()），就像程序员写代码一样自然。

这意味着，LLM即使没有看到数据的全貌，也能通过代码精确地操作数据。

动态上下文同步与观测整形

为了防止LLM写出 print(df) 这种让上下文爆炸的代码，CaveAgent引入了观测整形（Observation Shaping）机制。

• 智能截断：如果代码执行的输出超过了预设的长度限制 ，系统不会直接报错，也不会无脑截断。
• 反馈循环：系统会返回一个结构化的错误提示，告诉Agent：“输出太长了，请改用 .head() 或 .describe() 来查看摘要”。

这实际上是在“训练”Agent学会像数据科学家一样高效地探索数据，只关注关键信息。

静态分析带来的安全性

让AI写代码最怕什么？怕它写 os.system('rm -rf /')。CaveAgent在代码执行前加入了一层基于AST（抽象语法树）的静态分析。

• 黑名单机制：禁止导入 os, subprocess 等危险库，禁止使用 eval(), exec()。
• 结构化反馈：如果检测到违规，Agent会收到具体的 SecurityError，并被引导去修改代码，而不是让整个任务崩溃。

为RL（强化学习）提供完美的“代码级”奖励信号

如果您尝试过用强化学习（RL）来训练 Agent，您一定被“奖励函数（Reward Function）怎么写”这个问题折磨过。传统的做法是让一个LLM当裁判去打分（LLM-as-a-Judge），但这种基于文本的评价既昂贵又充满主观噪音。

CaveAgent 的架构无意中（或者说是精心设计地）解决了一个痛点：它让Agent的行为变得“程序化可验证”。

• 传统的模糊验证：Agent 输出了“任务完成，我已经把数据存好了”。是真的存好了吗？格式对吗？你只能靠猜，或者再写个正则去匹配文本。

• CaveAgent 的硬核验证：因为所有结果都是 Python 对象，我们可以直接写代码进行断言（Assert）。

• 想验证数据清洗是否成功？直接检查 cleaned_df.isnull().sum() == 0。
• 想验证分类是否准确？直接比对 result_list == ground_truth_list。

这种确定性的、布尔值级别（True/False）的反馈，为RL训练提供了极其纯净、高信噪比的奖励信号（Reward Signal）。这意味着，利用CaveAgent的环境，可以通过PPO等算法高效地训练Agent，让它从“偶尔蒙对”进化到“稳定输出”。

实验分析：CaveAgent vs 传统Agent

研究者们在多个基准测试上对CaveAgent进行了残酷的对比测试，结果非常说明问题。

1.复杂状态管理：Tau-bench测试

Tau-bench是一个模拟真实世界复杂任务（如零售、航空票务）的基准测试。在Tau-bench的零售（Retail）领域任务中，Agent需要处理退款、修改订单等一系列操作，这些操作高度依赖对用户信息的记忆和状态更新。

• 结果：CaveAgent的成功率比JSON基线方法高出了10.5%。

• 原因分析：

• 循环与条件判断：CaveAgent生成的Python代码天生支持 for 循环和 if 判断。比如查找“寄往德克萨斯的订单”，它会写一个循环遍历所有订单。
• 相比之下：传统Agent通常比较“懒”。它会调用get_recent_order() 拿最近的一单，看一眼不是TX的，就放弃了，或者幻觉说“找不到”。这是因为JSON模式不支持循环逻辑，Agent倾向于单次检索。
• 另外，关于准确率。CaveAgent在并行调用（Parallel Function）上具有天然优势，不需要像某些模型那样强制Prompt才能并行。即使是小模型（Qwen3-Coder 30B + CaveAgent）也能达到94.4%的准确率，击败了GPT-5.1的原生 Function Calling (89.6%)。

2.省钱才是硬道理：Token效率

Token就是钱。CaveAgent在Token效率上的表现令人惊喜。

• 数据对比：在多轮任务中，CaveAgent的Token总消耗减少了28.4%。

• 核心逻辑：

• 传统方法：每一轮都要把之前所有的数据和对话历史重新喂给模型，Token消耗随轮数线性甚至指数级增长。
• CaveAgent：数据存在运行时里，Prompt里只有极短的代码和变量名引用。虽然生成的Python代码比JSON稍微长一点（+36.3%），但输入的Prompt Token大幅减少（-32.7%），总体上非常划算。

3.数据密集型任务：碾压式的胜利

研究者构建了一个包含数据查询、统计分析和可视化的基准测试，使用了真实的股票市场数据。

• 数据查询：CaveAgent成功率100%，Token消耗仅为传统方法的一半。传统方法因为要把查询结果打印出来，直接导致上下文溢出（Context Overflow）。

• 数据分析：涉及计算夏普比率、波动率等任务。

• CaveAgent：100%成功率。
• 传统JSON Agent：10%成功率。
• 为什么？因为传统Agent试图用LLM的大脑去“算数”，而CaveAgent是调用Python去“计算”。

实战验证

看到研究团队已经开源了cave-agent，我也亲自上手实践了一番。测试示例将模拟一个跨国零售企业的风控中心，模型使用DeepSeek-R1，数据集选择UCI Online Retail Dataset。

项目地址：

https://github.com/acodercat/cave-agent

• 场景目标：让CaveAgent自己从50多万条历史交易中，自动清洗数据，并成功挖掘出最可疑的“异常大单”（可能是欺诈或录入错误）。
• 数据规模：约540,000+ 行交易记录
• 包含字段：InvoiceNo (发票号), StockCode (商品代码), Description (描述), Quantity (数量), InvoiceDate (日期), UnitPrice (单价), CustomerID (客户ID), Country (国家)。

Agent分工：

1. Data Loader (数据专员)：负责从互联网URL直接流式读取CSV到内存（Pandas DataFrame）。
2. Data Cleaner (清洗专员)：负责过滤掉“退单”（负数）和“单价为0”的坏数据，并计算每笔订单的总金额 (Total = Quantity * UnitPrice)。
3. Risk Analyst (风控专家)：使用Scikit-learn的Isolation Forest (孤立森林) 算法，在不依赖人工规则的情况下，自动识别出偏离常态的异常高额交易。

输出：

• 商品：PAPER CRAFT , LITTLE BIRDIE
• 总额：$168,469.60 (16.8万英镑)
• 数量：80,995 最终得到的结果正确。这笔交易是UCI Online Retail数据集中极其著名的“离群值”（Outlier）。这是一笔真实发生的、极其反常的大额交易（可能是手工工艺品的批量采购或数据录入异常）。这段过程也非常真实地展现了LLM的局限性和CaveAgent框架的引导能力。

现象：

• Round 1 - 3 (Failed): Orchestrator试图让Cleaner打印数据摘要，结果Execution output too long。这是因为50万行数据的摘要信息超出了LLM的Context限制（3000字符）。
• Round 4 - 5 (Correction): CaveAgent的反馈机制发挥了作用（Output exceeded limit...）。Orchestrator意识到了问题，开始修改代码，加上了“静默执行”、“禁止任何过程输出”的指令。
• 最终结果: 虽然Orchestrator还在努力调整输出，但底层的逻辑（清洗、传递、训练）其实在Python Runtime里早就执行成功了。最后的主机端验证（Host Verification）直接从内存取到了top_anomaly，证明任务完美完成。

评价：

• 鲁棒性极强：即使LLM在“怎么打印日志”这个问题上纠结了5轮，核心的数据处理任务（清洗和训练）并没有因此中断或崩溃。因为数据是对象（Object），一直安全地躺在Python Runtime的内存里，从来没有因为Context溢出而丢失。语义流只负责拆解任务和使用变量，几百兆字节的数据由运行时流处理，如果把运行时流的数据强行塞进语义流（传统JSON Agent做法），LLM早就崩了。这正是CaveAgent相比传统JSON Agent的核心优势。

深度案例：为什么“有状态”如此重要？

为了让您更直观地理解CaveAgent的优势，我们来看一个论文中提到的智能家居案例。

场景：在家里开派对。

• 第1轮：“把音乐音量调到中等。”
• 系统状态：volume = 40。
• 第2轮：“派对开始了，把音乐再调大一点。”

传统Agent的困境：

它没有“记忆”。当您说“再调大一点”时，它不知道“现在”是多少。它必须去翻以前的对话记录，甚至可能产生幻觉，把音量重置回默认值，或者随机设一个数。

CaveAgent的操作：

它拥有持久化状态。在运行时流中，SmartHome对象的volume属性实实在在地躺在内存里。

• 面对第2轮指令，它生成的代码是：home.music.volume += 20。
• 执行后，音量准确地变成了。

这种基于相对增量的操作，只有在有状态的运行时环境中才能稳定实现。在长达40轮的连续对话测试中，CaveAgent展现了极高的稳定性，没有出现状态漂移。

展望未来：多Agent协作

论文最后提出了一个非常具有想象力的方向：基于共享运行时的多Agent协作（Shared-Runtime Multi-Agent Coordination）。

在目前的主流Agent框架中，Agent之间协作靠的是“发消息”。Agent A做完了数据分析，得把结果写成报告（文本）发给Agent B。这不仅慢，而且在转换过程中会丢失大量信息。

CaveAgent提出了一种“通过状态共享来沟通”的新范式：

• 多个Agent共享同一个Python运行时环境。
• Agent A处理完数据，生成了一个 DataFrame 对象，存入变量 processed_data。
• Agent B不需要等待文本报告，它直接在代码里引用 processed_data 这个变量即可。

这实现了零延迟、无损的信息传递。比如在模拟城镇（Town Simulation）中，一个Agent修改了全局的“天气”变量，其他所有Agent瞬间就能感知到，无需任何复杂的通信协议。

最后

CaveAgent的出现，标志着AI Agent从“基于文本的聊天机器人”向“基于代码的运行时操作者”迈出了关键一步。

它通过双流架构解决了上下文爆炸的问题，通过Python对象注入实现了复杂数据的无损操作，通过有状态管理解决了多轮对话中的遗忘问题。

对于开发者而言，这意味着我们终于可以构建出那样一种Agent：它不仅能陪您聊天，还能像一个经验丰富的数据工程师一样，在后台稳健、精准地操作您的数据库、API和业务逻辑，而且还更省钱。

如果您的业务场景涉及复杂的数据处理或长流程的逻辑控制，CaveAgent所倡导的“Code as Action, State as Memory”的理念，绝对值得您重点关注。

文章来自于微信公众号 “AI修猫Prompt”，作者 “AI修猫Prompt”