OpenHands：AI 软件代理开放平台及其对财务自动化的意义
我经常看到 OpenHands 被作为 TheAgentCompany、InvestorBench 以及越来越多评估论文的基础层——但我还没有读过它的核心论文。这是该领域其他研究正在悄然构建的基础设施，因此了解它究竟提供了什么、在哪些方面存在不足，比建立在它之上的任何单一基准测试结果都更重要。
论文解读
OpenHands（Wang 等人，2024；ICLR 2025）是一个用于构建和评估充当通用软件开发者的 LLM 代理的开源平台。由 Xingyao Wang 和 Graham Neubig 领导的 24 人团队在论文中提出，大多数现有的代理框架要么研究范围过窄（硬编码任务循环），要么生产范围过窄（闭源或单一用途），难以作为研究社区的共享基础。OpenHands 试图通过在一个 MIT 许可的代码库中提供标准化的运行时、清晰的代理抽象和 15 个集成的评估基准来解决这个问题。
其运行时是 一个包含 Bash Shell、Jupyter IPython 服务器和 Playwright 控制的 Chromium 浏览器的 Docker 沙箱环境。代理通过三种主要的动作类型进行交互：用于 Python 的 IPythonRunCellAction、用于 Shell 命令的 CmdRunAction 以及用于网页导航的 BrowserInteractiveAction。一个多代理协调原语 AgentDelegateAction 允许主代理生成专门的子代理。默认骨干是 CodeAct——最初作为一篇独立论文发表，主张代码是 LLM 代理理想的统一动作空间——该平台发布了几种代理实现，包括通用的 CodeActAgent 和专门的 BrowsingAgent。
核心观点
- 代码作为通用动作空间：CodeAct 将所有代理操作（文件编辑、API 调用、数据转换）整合到 Python 或 Bash 中，让 LLM 在其训练最充分的媒介中进行推理。这避开了困扰函数调用（function-calling）代理的脆弱 JSON 模式问题。
- 沙箱化 Docker 运行时：每个代理都在隔离的容器中运行，因此代理可以自由执行任意代码而不会危及宿主机——这是任何可能被授予真实凭据的生产级财务代理的先决条件。
- 15 个基准测试集成：SWE-Bench Lite（代码修复）、HumanEvalFix（错误修复）、WebArena（网页导航）、GPQA（研究生水平推理）、GAIA（通用任务解决）等 15 个基准测试。将这些测试集成在一起可以防止选择性评估。
- CodeActAgent + claude-3.5-sonnet 在 SWE-Bench Lite 上达到了 26%，在 HumanEvalFix 上达到了 79.3%；BrowsingAgent 在 WebArena 上达到了 15.5%——在没有任何特定任务训练的情况下实现了极具竞争力的零样本表现。
- GAIA 性能：使用 GPTSwarm 时为 32.1%，远低于 92% 的人类基准——这与所有其他通用代理基准测试显示的 60-70 分的人机差距一致。
- 社区规模：在提交 ICLR 时已拥有 7.14 万个 GitHub Star 和 188 多名贡献者；TheAgentCompany 采用了 OpenHands 作为其评估框架，赋予了其事实上的基准基础设施地位。
哪些经得起推敲，哪些不能
沙箱化运行时设计是扎实的工程实践。在 Docker 中隔离代理执行是任何后续可能被赋予真实财务账本写入权限系统的正确默认选择，而且将基准测试并列放置而非散布在不兼容的代码库中确实很有用。
然而，基准测试的覆盖范围更多是愿景式的而非系统性的。15 个基准测试跨越了完全不同的任务类型和难度级别，缺乏关于如何汇总或比较结果的明确框架。在同一篇论文中报告 SWE-Bench Lite 26% 的成绩和 HumanEvalFix 79.3% 的成绩，可能会产生同一个代理既平庸又优秀的错觉——这些任务根本不具可比性。作者没有提供原则性的多基准汇总方法。
关于 CodeAct 的假设——即代码是正确的通用动作格式——存在争议。它在开发任务中表现良好，但在每个动作上都强加了一个 Python/Bash 中介层，这增加了延迟，并且当动作语义无法清晰映射到代码时（模糊的用户指令、仅限自然语言的 API）会失效。论文没有针对非代码动作空间进行基准测试，以证明这种优势是真实的，而不是由 LLM 骨干网络产生的混淆。
也许最重要的差距在于评估与部署的分离。26% 的 SWE-Bench 数据来自一个相对干净、规范明确的基准测试。社区报告和 GitHub Issue 讨论一致描述了在模糊或长程的现实任务中可靠性要低得多——这正是 TheAgentCompany 记录的失败模式。论文没有讨论如何在现实的任务规范噪声下衡量或提高稳健性。
为什么这对财务 AI 至关重要
OpenHands 是目前社区拥有的最接近共享代理基板的东西。如果 Bean Labs 为 Beancount 代理构建评估基础设施，这里的运行时架构——Docker 沙箱、Python/Bash 动作、可插拔的 LLM 后端——值得采用而非重新构建。AgentDelegateAction 原语自然地映射到财务代理流水线中，其中顶级协调器授权给专门的子代理：一个用于账本读取，一个用于异常标记，一个用于由人工审核的拟议回写。
结合 SWE-Bench 和 TheAgentCompany 的数据，建立了一个令人清醒的先验认知：即使是目前最好的代理，也只能完成大约 26-30% 的现实、明确的软件任务。财务账本自动化更难——交易往往是模糊的，错误的影响范围是真实存在的，而且用户意图经常定义不足。正确的推论不是代理还没准备好，而是首批富有成效的部署将是范围严格受限的一次性写入工作流（分类建议、对账标记），而不是自主的多步骤账本编辑。
下一步阅读建议
- ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) —— 将廉价模型与昂贵模型配对，仅在不确定性较高时才转交给昂贵模型；直接解决了 OpenHands 风格的代理应如何决定何时将 Beancount 回写上报给人工审核。
- FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) —— 跨越 34 个财务场景的 800 个专家标注的任务序列；提供了 OpenHands 在财务特定长程工具使用方面所缺乏的评估方法。
- FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) —— 涵盖 65 个真实 MCP 财务工具的 613 个样本，直接关系到构建在 OpenHands 运行时上的 Beancount 代理在真实 MCP 部署中将如何被评估。
