Render Unto Caesar

将凯撒之事交给凯撒（RUC）（ruc-mcp）

将凯撒之事交给凯撒（RUC） 可接入你的 AI Agent，让它能够按需编写并运行代码片段；这些代码片段在执行过程中还会直接回调 AI Agent。它实际上将大模型与传统软件融为一体，让任务的每个部分都由最适合处理它的架构来完成。因此，即使面对长时间运行、大型数据集和复杂流程，推理、判断和创造力也能以有条不紊、可靠的方式执行。

在同一集成工作流中兼顾确定性执行与大模型判断

如果你造了一台机器，其唯一目的就是让它不那么像机器，但你仍然让它做机器擅长的事，那你就要吃苦头了。

基础模型开发者不断训练大模型，让它们更忠实地遵循用户指令。他们耗费了数不尽的千兆焦耳能源和漫长的 CPU/GPU 时间，试图让神经网络——从根本上说，本质就是反复无常的概率性存在——按照给定顺序执行步骤，并且不被干扰、不提前宣告完成，也不凭空编造完全未经要求的操作。

优化这个方向很荒唐。

我们早就有能精确、重复、孜孜不倦地遵循指令的机器了。它们叫作计算机。

神经网络不是好计算机。没错，神经网络运行在计算机上，但仅凭这一点，并不会让它们神奇地拥有像计算机那样工作的能力——就像你由细胞构成，并不意味着你自然就成了微生物学家。

神经网络不是因为需要更多强化学习才算不上好计算机。它们算不上好计算机，是因为它们不是计算机。它们是模式补全引擎：强大、灵活、模糊、善于联想，且极其有用——但从根本上说，并不适合执行漫长的流程。

这甚至并非人工神经网络独有的问题。人脑在这方面也不擅长。这就是为什么我们做长除法时得用铅笔，也就是为什么我们要用清单、日历、食谱卡片、覆膜流程图和便利贴。这叫作“外化认知”。这是一种几乎只有我们这个物种才有的超能力：我们聪明到能意识到自己在哪些方面不聪明，并用工具来弥补自身智能的不足。外化认知之所以存在，正是因为神经认知无法可靠地执行流程。

RUC 正是围绕这一差异构建的：让神经网络负责理解、判断和创造；让计算机负责执行。

大模型非常适合作为任务请求的接口，却不适合作为任务执行引擎。它们擅长撰写文字和评估杂乱或模糊的信息，却不擅长执行漫长、精确的流程。当一项操作既需要大模型的灵活性，又需要传统代码的严谨有序时，**将凯撒之事交给凯撒（RUC）**便能弥合这一差距。RUC 将工作拆分为需要理解的部分和需要机器处理的部分，并让两者协同运作，为你兼得两全之利。

现代大模型应用让人们可以很自然地用通俗英语请求完成复杂工作。问题在于，通俗英语请求往往把大模型擅长的事和众所周知不擅长的事混在一起。用户可能会让 ChatGPT、Claude 或 Cursor 审核支持工单、补齐电子表格中的缺失数据，或为一系列广告集思广益。这些任务需要判断力和创造力，但也需要循环、计数、状态、验证、一致性和可审计性——这些正是传统代码的用武之地。 即使是工程师，大多数用户在提出任务需求时，也不会自然而然地把这两个层面区分开来。他们描述的是自己想要的结果，而不是可靠地产生该结果所需的架构。RUC 会替他们完成这种区分。它会识别哪些部分需要确定性执行——例如迭代、算术运算、验证、状态管理和可审计性；哪些部分需要分类、摘要、消除歧义或自由写作。它会定义这些部分之间的接口，说明如何将适合用代码处理的工作传入适合由大模型处理的工作，以及如何将大模型处理后的结果传回程序化执行环节。这让两类工作能够协同进行：代码提供结构、连续性和严谨性，而大模型则在僵化规则难以胜任时处理细微差别。

最终，系统能够以程序化软件的控制力、结构性和可重复性，完成适合由大模型处理的工作。

核心理念

Render Unto Caesar 建立在一个简单的分工之上：

• 代码负责处理 循环、算术运算、验证、重试、文件、进度跟踪、汇总和状态管理。
• 大模型负责处理 语言理解、创意写作、分类、摘要、消除歧义、模糊匹配和其他语义判断。

关键不只是两者都可用。关键在于 RUC 定义了两者之间的边界，让程序化代码和大模型判断能够在同一个工作流中安全协作。

适用对象

RUC 面向业务和工程专业人士，他们希望描述一系列要计算机执行的操作，并且期望计算机像一台计算机那样执行这些操作，而不是像某种弹珠游戏。

在实践中，这通常包括：

• 处理大型 CSV 或电子表格导出的产品负责人和 PM。
• 执行重复的数据清理、分类和规范化任务的分析师及运营团队。
• 对数据质量成果负责的领域负责人和数据管理员。
• 在 VS Code 中为非工程团队成员提供支持的工程师和 AI 工具高级用户。

RUC 能发挥作用的示例场景

1. 一位 PM 需要在路线图评审前对 1,700 条支持反馈工单进行分类处理。
2. 一位财务分析师拥有数百场财报电话会议的文字记录。分析师需要填写一份电子表格，详细记录是哪家公司召开了会议、会议日期、参会人员、讨论了哪些关键指标，以及这些指标的具体数值。
3. 一位区域销售经理需要将 7,000 条自由文本客户调查评论分类整理，分类依据是每位客户重点描述了产品的哪些功能。
4. 一位全国广告主管希望为美国全部 3,144 个县分别制作定制广告文案。

安装指南

以下说明假设你熟悉一些命令行工具。幸运的是，即使你自己不熟悉这些工具，你的 AI Agent 也熟悉！如果你正在阅读本文，却不知道如何完成其中某些步骤，可以告诉你的 Agent：“帮助我按照 https://github.com/mightydatainc/ruc-mcp 上的安装指南进行操作。”它会知道该怎么做。

先决条件

运行 RUC 需要安装 Docker。

RUC 是一个在 Docker 容器内运行的 MCP 服务。如果你不熟悉这些概念，以下介绍可能会有所帮助：

• Model Context Protocol (MCP)：一种通信标准，允许“宿主端”（例如 VS Code 或 Claude Desktop 可执行文件）加载第三方工具系统（例如 RUC），并向其大模型（无论是基于云端还是在本地运行）告知这些工具提供的能力，以及根据大模型的请求调用这些工具。
• Docker：一种轻量级虚拟化系统，可让你在真实计算机中模拟运行迷你计算机（大致如此）。它在安全、依赖项管理和可移植性等方面很有用。

请根据你的操作系统，按照指南安装 Docker：

• Windows
• Mac
• Linux

与 AI Agent 集成

⚠️ 你的 Agentic AI 环境必须支持 MCP SAMPLING！ ⚠️

“Render Unto Caesar” 完全依赖一种名为 "sampling" 的 MCP 能力。没有 sampling，它将无法运行。

目前，唯一支持 sampling 的热门 Agentic AI 宿主端是 VS Code（搭配 GitHub Copilot）。

VS Code

安装 VS Code 扩展。

1. 在 VS Code 中打开“扩展”。
2. 搜索“Render Unto Caesar”。
3. 安装由 mightydatainc 发布的扩展。下载 Docker 镜像可能需要几分钟。（镜像并不特别大，但由于安全检查、注册表更新等原因，下载仍可能需要一段时间。）

三步搞定！

如需验证是否安装正确，请打开命令面板（Control-Shift-P），输入 MCP: List Servers，按 Enter，并确认“Render Unto Caesar”已显示。

让 MCP 客户端的 AI 自行处理

这始终是一个备用选项。无论你使用什么 MCP 客户端或宿主端（只要它支持 sampling！），都可以直接让它自行弄清楚如何启动并连接到此 MCP 服务。告诉客户端以下信息可能会有所帮助：

• RUC 通过 STDIO 与客户端通信。
• 它的命令行调用形式如下：

docker run --rm -i \
-e RUC_MCP_LOG_LEVEL=DEBUG \
-e RUC_MCP_HOST_WORKSPACE=${workspaceFolder} \
-v ${workspaceFolder}:/workspace \
ghcr.io/mightydatainc/ruc-mcp:latest

开发

先决条件

可选：从 GitHub Container Repository (GHCR) 拉取 Docker 镜像

你可能不需要自己执行此操作，因为大多数安装方式都会自动完成。但这里仍提供相关步骤以供参考。

docker pull ghcr.io/mightydatainc/ruc-mcp:latest

在本地构建 Docker 镜像

docker build -t mightydatainc/ruc-mcp:local . --no-cache

（--no-cache 标志是可选的。指定该标志时，Docker 会从头开始重新构建镜像。如果省略，且已有镜像，Docker 会基于该镜像进行构建。）

运行测试

python -m unittest discover -s tests -p "test*.py"

发布检查清单

打标签前：

1. 确保 main 上的 CI 全部通过。
2. 确认 GitHub Actions 有权限写入软件包。
3. 确认 GHCR 的软件包可见性方案（公开或私有）。
4. 更新你希望随标签一同发布的任何发行说明或更新日志内容。

发布步骤：

1. 拉取最新的 main。
2. 创建并推送版本标签（vX.Y.Z）。
3. 等待 Publish Docker image to GHCR 完成。
4. 确认 GHCR 中存在镜像标签（vX.Y.Z、X.Y.Z 和 latest）。

发布后验证：

1. 在本地拉取新镜像。
2. 使用示例 MCP 调用运行容器。
3. 确认客户端配置引用了预期的标签。

CI 和发布自动化

• CI 会在推送到 main 时以及针对拉取请求运行。
• 推送到 GHCR 的 Docker 发布会在匹配 v* 的版本标签上自动执行。

要发布镜像，请推送类似这样的标签：

git tag v0.1.0
git push origin v0.1.0

这会将以下标签推送到 GHCR：

• ghcr.io/mightydatainc/ruc-mcp:v0.1.0
• ghcr.io/mightydatainc/ruc-mcp:0.1.0
• ghcr.io/mightydatainc/ruc-mcp:latest

状态

2026-05-24 — v0.1.2 添加了用于处理 Excel 文件、HTML、PDF 等的库。 2026-05-23 — 首次发布：v0.1.0 已发布到 GitHub 容器仓库（GHCR）。

未来扩展

• 添加可恢复的执行行为，以便中断的运行能够从已保存的进度继续。
• 为频繁请求的工作流添加缓存，以减少重复生成的开销。
• 添加网络访问
  • 需要一种限制页面加载量的方法
  • 需要一种以文本形式向大模型呈现页面内容的方法
  • 需要一种运行真实浏览器的方法
    • 利用 JavaScript
    • 利用具有语义意义的布局细节（例如，display: none 或 opacity: 0 的元素不计入）
    • 可能会利用用户的 Cookie、现有登录状态等
• 添加对 MCP 采样工具调用的支持
  • VS Code 无论如何都不支持采样工具调用
  • 采样工具支持应设为有条件启用
    • 结构化 JSON 目前也已设为有条件启用
• 是否可以用 WebAssembly 代替 Docker？