AgentRun 评测：AI 智能体工作流何时值得引入

AgentRun 评测：它在 AI 智能体工作流中做什么

AgentRun 是 Parcha 推出的 TypeScript 工作流解释器，用确定性结构把工具、范围明确的模型决策和 agent 调用组织起来。Parcha 于 2026年9月23日将其开源。工作流文档负责声明状态契约、步骤、分支、限制和升级路径；工具、模型访问、权限、存储与交付则由应用提供。它不是 Alibaba Cloud 的同名产品，也不是那个用于执行模型生成代码的旧 Python 包，更不是至今仍会出现在搜索结果里的 2014 年手机游戏。目前的核心包是采用 Apache-2.0 许可的 @parcha/agentrun-dsl version 0.1.0-beta.4。

哪些团队适合 Parcha AgentRun，哪些不适合

AgentRun 适合这样的 TypeScript 团队：已经有 agent runtime，也能明确指出某项重复任务因为普通代码难以检查而变得棘手。客服分流就是典型场景：先搜索，再判断答案是否充分；只有需要调查时才花费一次 agent 调用，之后返回结果或转交人工。证据筛查、审批路由和研究管线也有相同结构。当产品、运营或风险负责人需要直接看懂控制流，而不是沿着一串回调追踪时，它的价值最明显。

如果任务只是一个固定函数，里面只有两三个一眼就能看懂的分支，就不必用 AgentRun。本次评测的对照实现用 31 行函数体就覆盖了全部 4 种支持结果，而 AgentRun 示例工作流仅文件本身就有 93 行，尚未计算宿主集成。论代码短，函数显然更胜一筹。

如果核心问题是让有状态 agent 长时间运行，并支持持久化、流式输出和人工中断，应选择 LangGraph.js。如果不可妥协的要求，是让应用执行跨越崩溃、网络故障和长时间等待后仍可恢复，应选择 Temporal。AgentRun 暴露了恢复钩子，但本身并不是一套打包好的持久调度器。如果团队需要 Python、浏览器执行、托管控制台或生产支持 SLA，beta.4 同样不合适，因为这个版本都不提供。

能力一：类型化状态能拦住契约漂移

AgentRun DSL 的第一个价值，是当最终值不再符合声明的契约时直接拒绝交付。这听起来只是基础能力，但工作流一旦同时包含搜索结果、语义决策和 agent 提交，如果没有最终校验器，任何分支里的数据结构变化都可能以“部分成功”的形式流到调用方。

这个支持工作流区分了宽松的 Candidate 与最终的 Answer。搜索结果可以是空文本，也可以没有来源，因为这种情况允许触发调查；完成条件则严格得多：最终答案必须包含非空文本和至少一个来源。编写指南还会校验声明的输入、输出契约，而中间状态路径则在执行期间接受检查。

契约测试新增了一个必填字段，却没有修改 fixture 输出：

schemaWorkflow.schemas.Answer.properties.resolutionCode = {
  type: 'string',
  minLength: 1,
};
schemaWorkflow.schemas.Answer.required.push('resolutionCode');

密码路径照常完成了帮助信息查询和第一次决策，但在结束时因为缺少 resolutionCode，以 WorkflowOutputInvalidError、错误码 output_invalid 失败。无效答案没有被返回。这正是合理的失败方式：系统在边界处停下，而不是把一个语义上看似合理的对象当成契约完整的结果。

这层保护也有明确上限。格式有效的 text 字符串和 sources 数组，内容依然可能是错的。Schema 校验只能证明下游代码可以消费这个值，不能证明客户应该相信它。配套的 Jev 支持工单路由评测讨论了决策层的问题：概率与类型化输出仍然需要带标签的案例和人工兜底。

能力二：分支控制为 agent 调用设定上限

AgentRun 的工作流控制在 4 个支持案例里严格走完了图中规定的路径：两个请求在搜索和一次决策后结束，另两个请求则进入一次有界调查，并再做一次决策。这里真正有用的单元并非“自主 agent”，而是一条确定性路径，其中只有一个位置可以调用 agent。

每个 fixture 的直接运行结果都与文档一致。密码、发票和支付失败案例返回代码 0；未解决的支付案例返回代码 2，理由是一次调查后答案仍然不充分或不确定。4 次运行写入 stderr 的字节数均为零。仓库中聚焦支持流程的测试套件也全部通过：31 项测试耗时 2.92 秒，覆盖了无效提交、低置信度决策、取消和 adapter 错误等情况。

这些结果证明的是调用纪律，而不是客服质量。搜索答案、Jev 决策和调查输出都来自固定 fixture；更换 prompt 不会让它们自行适应，也不会真的向客户发送回复。这次运行验证的范围更窄，却很实用：第一个答案通过时，解释器不会消耗 agent 调用；失败时，只允许一次调查；第二次检查仍失败时，案例不会以完成状态漏出。

这也是采用该 runtime 最有说服力的理由。通用 agent loop 可能因为对话看起来尚未结束，就再次搜索、再次修改，或再调用一个工具。AgentRun 则直接在工作流里把允许执行的工作限定为有限集合。因此，运营人员可以在运行前检查调用预算，尽管供应商费用和工具权限仍须由宿主强制执行。

能力三：升级是代码，不是 prompt 里的愿望

AgentRun 会把升级转化为带原因的 runtime 状态，而不是埋在 agent prompt 里的一句话。测试工作流只有在决策为 yes、答案符合契约且置信度达到 0.8 时才接受结果。否则，它会打开一个零次或一次的调查队列，再次检查结果；同一道门槛仍未通过，就进入升级状态。

为了验证这个数字是否真的控制行为，测试把两处比较值都从 0.8 提高到 0.98。密码 fixture 的脚本决策仍是 yes，置信度为 0.97。在原工作流里，该案例无需 agent 调用便立即完成；门槛收紧后，它进入调查，得到同一个有效答案，又返回一次置信度为 0.97 的 yes，最后在一次 agent 调用和两次决策后升级。

这个小改动没有触碰 prompt、fixture 答案或 adapter，却改变了分支。这正是把置信度策略写进代码的实际优势：团队可以像审查其他行为变更一样审查阈值，先用带标签的案例运行，再在发布前查看由此产生的转人工比例。

升级也与交付保持分离。Runtime 返回 complete 或 escalated；至于创建支持工单、提醒人员还是不做任何事，由宿主决定。这样的分工可以避免工作流文档自行获得联系客户或修改账户的权限。

能力四：检查很有用，集成仍要自己完成

AgentRun 的检查能力能让工作流在代码执行前变得可读，但不会替你完成外围应用工作。在生成的分流示例中，agentrun inspect 返回了工作流 digest、judge、escalate 和 code 节点、必需的 runJudge adapter，以及 executableCode: true。validate 返回 ok: true；dry-run 也返回 ok: true，同时明确说明模拟的升级路径被跳过。

这个“跳过”很重要。绿色的 dry run 只能证明接线无误，不能证明分支覆盖。行为证据来自 4 个支持 fixture，因为它们刻意走过了返回、调查和复核路径。在 CI 中也应保留这种区分：inspection 检查结构，validation 检查契约，固定案例检查行为。

集成主要需要 3 个适配器。runEffect 负责分派工具和其他 effect；runJudge 提供类型化决策，也可以通过 Jev 实现；runNode 连接 agent runtime，并且必须转发 schema、工具、取消 signal 以及所有复核 callback。认证、密钥、模型选择、轮次上限、预算、日志、脱敏、交付和持久 receipt 也都归宿主管理。

普通函数这个对照组把取舍衬托得更清楚。它的 31 行函数体使用同一组脚本化适配器，并复现了所有基线状态和调用次数。只有一条支持路由时，这个函数更容易阅读和上线。AgentRun 工作流文件多出的 62 行，换来的是可复用文档、通用检查、共享节点语义、输出契约、结构化升级，以及可由 authoring agent 生成的界面；默认情况下，它并不会减少代码量。

这与更广义的 内部 agent 工作流自建还是采购判断遵循同一条边界：只有重复运营工作的成本超过维护共享机制的成本，才值得引入通用基础设施。

AgentRun Beta 定价：解释器免费，Runtime 并不免费

AgentRun beta 的软件价格只有一个：Apache-2.0 代码费用为 $0。beta.4 没有付费 AgentRun 套餐，也没有托管的 AgentRun runtime。npm 包、源码、CLI、工作流解释器和示例就是产品本身。Parcha 不会在这份许可中附带模型 token、工具执行、存储、可观测性或生产支持。

Jev 是单独计费的可选决策模型。经 TypeSafe 实时模型页面于 2026年9月24日核实，Jev 1.13 的每百万输入 token 价格为 $0.042，输出 token 免费。按照每次决策输入 500 token 的既定假设，一次检查成本为 $0.000021，两次检查为 $0.000042。处理 100,000 个案例时，这些决策调用的总成本分别是 $2.10 或 $4.20。

这笔算术没有包含 agent 调查。AgentRun 可以连接宿主提供的任意 agent runtime，因此不存在一个诚实、通用的单案例价格。只做一次 Jev 检查便结束的支持案例，与需要 agent、工具、第二次检查、存储、日志和人工复核的案例，成本结构完全不同。本次脚本化评测没有调用实时模型，因此观测到的推理开销为 $0，同样也没有任何生产成本证据。

Temporal 很能说明为什么持久托管是另一项采购。Temporal Cloud 目前的起价是每百万次操作 $50，另计存储费用，并提供 90 天内可用的 $150 额度。AgentRun 不收这类平台费，是因为它并未提供可与之相比的托管执行层。

真正需要注意的限制

AgentRun 的限制足以决定一种谨慎的引入方式：让 beta 先进入一个边界明确的工作流，而不是直接成为默认架构。

1. 发布产物对自己的版本说法不一

已发布的 package manifest把安装包标为 0.1.0-beta.4，但包内的 README写的却是 Beta: 0.1.0-beta.3。beta.4 tag 的根 README 同样把版本称为 beta.3，changelog 甚至仍将 beta.4 标记为未发布。当前 main 已把根 README 改为 beta.4，但买方如果固定到已发布 tag，看到的依然是互相矛盾的状态文字。

这不会破坏解释器，却对强调版本来源的工作流系统很重要。应固定 npm 版本，保存 workflow digest，并分别记录 adapter 和策略版本。不要依赖一枚文字 badge 来还原某次生产运行。

2. 宿主负担就是产品边界

AgentRun 提供控制流，并不提供完整的支持系统。认证后的工具、agent adapter、Jev 访问（如果使用）、secret、预算执行、取消、私有诊断、客户数据策略、交付、监控和人工复核处理，仍要自行完成。30.48 秒的源码安装数据，完全不能代表这些集成工作量。

3. 恢复钩子不等于持久执行

Runtime 提供了 checkpoint、memo、receipt 和 recovery 接口，但存储与对账由宿主实现。Idempotency key 有助于去重，却不能保证 exactly-once delivery。已经超时的外部 effect 仍可能最终完成；宿主必须先检查其最终结算状态，再决定是否重试。如果首要需求是崩溃恢复，请使用 Temporal；如果首要需求是持久化的有状态 agent 图，请评估 LangGraph.js。

4. 可信 JavaScript 是一道严格的安全边界

代码节点以进程权限执行 JavaScript，校验过程也可以运行 probe。CLI 的 --trusted 标志只是风险确认，并不是 sandbox。如果团队要接收来自用户、生成式产物或其他信任域的工作流，就必须用宿主控制的进程、文件系统、网络与凭据边界将其隔离。

5. 类型正确的结果，依然可能自信地出错

Schema 测试如预期失败，但它发现不了结构完整的错误答案。高置信度的 yes 决策依然只是模型结果。工作流需要带标签的案例、针对任务的阈值、生产监控和复核路径。通过的 31 项支持测试只验证了所提供的场景，并不代表 Jev 的实时准确率。

6. 平台和支持选项都很有限

beta.4 是 Node.js ESM 库，最低要求为 Node 22.19；TypeScript 使用者的最低版本为 TypeScript 5.4。Python、浏览器执行和托管 runtime 都不在范围内。该 beta 没有生产支持 SLA，而且 beta 版本之间的 API 或执行变化可能要求迁移。

7. 固定函数比想象中更常成为更好的抽象

31 行的对照函数并不是一个凑数的反例，它在全部 4 个脚本案例中都复现了工作流结果。如果任务只有一次搜索、一个条件、一次可选 agent 调用和一次由同一团队负责的转交，函数的局部性更好，引入的概念也更少。只有当工作流本身需要独立于外围应用接受检查、生成、版本管理、组合或评估时，AgentRun 才真正成立。

在运营层面采用之前，还应配套规划失败证据。AI agent 故障分析工具指南介绍了当顺利路径上的图已经不够用时，应该保留哪些日志和 trace。

结论：AgentRun 什么时候值得引入

作为一款把 agent 任务中可重复的中间部分变成显式软件的 beta，AgentRun 是可信的。它的解释器安装轻松，支持流程图按预期走完所有有界分支，输出契约能够失败关闭，阈值也确实像代码一样控制行为。这个项目对库外仍需自行承担的工作，说明得格外直接。

不过，结论依然带有前提。只有以下 4 项全部成立，才应选择 AgentRun： 工作流会反复执行；至少一个模型或 agent 分支需要清晰可见的上限；不止一个人或系统需要检查或生成该工作流；宿主有能力负责 adapter、权限、恢复、评估和交付。任何一项不成立，都应先从 TypeScript 函数做起。

如果产品本质上是持久化 agent 图，使用 LangGraph.js；如果本质上是持久化分布式流程，使用 Temporal。AgentRun 位于它们与普通函数之间：比两类 runtime 都窄，但比手写控制代码更有结构。

下一步很具体：挑一项现有 agent 任务，把每个步骤分别标成确定性代码、类型化决策、agent 调查或人工复核。如果图里只有一条固定直线，就保留函数；如果存在反复出现的分支，而且 agent 开销或升级策略需要审查，就把那一条路径编码进 AgentRun，固定 beta.4，并在接入实时模型前先建立 4 个 fixture。

AgentRun 常见问题