带有状态REPL的代码模式

我一直致力于开发 `ptc_runner_mcp`——一个 MCP 服务器，它为 AI 智能体提供一个有状态、沙盒化的 REPL，使用类似 Clojure 的小型语言。在使用 MCP 的过程中，我反复遇到的问题不仅仅是工具发现，更是工具调用之后发生了什么。许多智能体任务本质上是探索性计算任务。如果所有数据都回流到模型上下文中，LLM 就会开始在“脑子里”做计算——这就是错误结果和上下文窗口缩水的根源。`ptc_runner_mcp` 暴露了一个主要工具：`lisp_eval`。在 `lisp_eval` 内部，智能体获得一个类似 REPL 的会话。它可以检查可用的 MCP 服务器/工具，调用它们，将结果存储在会话内存中，定义辅助函数，并在同一状态下继续工作。发现过程也是 REPL 形态的——智能体无需将每个工具的模式预先推入上下文，而是可以使用它已经理解的东西：`(mcp/servers)` `(dir 'github)` `(doc 'github/search_issues)` `(apropos "calendar")`。然后它可以发起一个小的探测调用，了解结果形状，获取真正的数据，并在本地进行计算。例如，它无需将 1000 条记录拉入对话中，而是可以这样操作： ```clojure (def traces (fetch-all-traces "org-acme" "production")) (defn cost [t] (Double/parseDouble (get t "total_cost"))) (->> traces (group-by day) (map (fn [[day xs]] {:day day :total (reduce + (map cost xs))})) (sort-by :total)) ``` 模型看到的是计算的结果（如果太长则会被截断）。在下一轮交互中，它可以继续使用已定义的辅助函数。 我采用这种方式的另一个原因是性能和运维的简洁性。会话运行在 BEAM 上，因此非常轻量。你可以在单台机器上保持大量并发、有状态的 REPL 会话并保持低延迟，而无需管理一个由更笨重的 Python/JS 沙盒组成的池。