MIT JAZ 研究：Harness as a Language，用声明式编排解决 Agent 工程化难题

1. 从"写提示词"到"造工具"：JAZ 到底在解决什么问题

大多数人接触 Agent 开发，第一反应是去调 API、拼 prompt、接几个工具函数，然后发现一个尴尬的事实：模型能力在涨，但你的 Agent 还是那副样子——换个任务就得重写一遍流程，加个新工具就得改一遍代码，想复用上次跑通的逻辑，只能靠复制粘贴。这不是模型的问题，是编排层的问题。

MIT 这项新研究提出的 JAZ，核心主张就一句话：Harness as a Language。翻译成人话就是——把"驾驭 Agent 的那套东西"从代码里抽出来，变成一门语言。你不再是用 Python 写一堆 if-else 去控制 Agent 该调哪个工具、该走哪条分支，而是用一种声明式的语法去描述"这个 Agent 在什么条件下做什么"。

这里要先厘清一个被热词搅浑的概念：Harness 和 Agent 到底啥区别。Agent 是"干活的主体"，它包含模型、记忆、工具集；Harness 是"套在 Agent 外面的那层壳"，负责调度、约束、编排、观测。打个比方，Agent 是司机，Harness 是方向盘加导航加行车记录仪。很多人把两者混为一谈，结果写出来的代码既当司机又当方向盘，耦合得一塌糊涂，改一处崩三处。

JAZ 想干的事，就是让 Harness 这层壳拥有自己的表达方式。它引入了几个关键概念：Primitive（原语）、invoke（调用）、Harness 工程。原语是最小的可组合单元，比如"读取一个文件""调用一次模型""判断一个条件"；invoke 是把原语串起来的动作；而 Harness 工程，就是把这些原语和调用组织成一套可维护、可复用、可测试的编排逻辑。

为什么这件事值得单独拿出来讲？因为现在 Agent 开发的痛点，几乎全集中在编排层。你去看那些真实落地的 Agent 项目，模型调用本身往往只占代码量的两成，剩下八成全是状态管理、错误重试、工具路由、上下文裁剪、并发控制。这些活儿琐碎、重复、容易出错，而且每换一个业务场景就得重来一遍。JAZ 的价值就在于，它试图给这八成脏活累活提供一套统一的、声明式的表达方式。

适合谁来读这篇？如果你正在做 Agent 开发，被编排逻辑折磨过；如果你在评估 Agent 框架，想知道"声明式编排"这条路走不走得通；如果你只是好奇 MIT 又在搞什么新花样——都能从下面这些拆解里拿到东西。我会尽量把 JAZ 的设计思路、它和现有方案的区别、以及如果你要上手该怎么落地，讲得能直接抄作业。

2. Harness as a Language 的设计哲学：为什么是"语言"而不是"框架"

2.1 框架的困境：你永远在填它的坑

先说说为什么现有的 Agent 框架让人又爱又恨。主流的 Agent 框架，无论是偏编排的还是偏工具集的，本质上都是命令式的——你得用宿主语言（Python、TypeScript）去写控制流。框架给你提供了一堆抽象类、装饰器、回调钩子，你按照它的规矩把逻辑填进去。

问题出在"填"这个动作上。框架的抽象层次是固定的，但你的业务需求是流动的。框架假设你会按 A→B→C 的顺序走，结果你的场景需要 A→C→B 或者 A→(B|C)；框架假设工具调用是同步的，结果你遇到一个必须异步等待的外部服务；框架假设错误处理就是重试三次，结果你需要根据错误类型走完全不同的补偿路径。每一次这种"框架假设"和"实际需求"的错位，你都得用宿主语言的代码去绕、去 hack、去写适配层。

绕到最后，你的项目里框架代码和业务代码搅在一起，谁也说不清哪行是框架的规矩、哪行是你的补丁。想升级框架版本？先祈祷它没改那些你 hack 过的内部接口。想把编排逻辑复用到另一个项目？对不起，它和这个项目的业务代码焊死了。

2.2 语言的优势：表达力与可组合性

JAZ 选择"语言"这条路，本质上是想解决表达力和可组合性这两个框架解决不好的问题。

语言的第一优势是声明式。你描述"要什么"，而不是"怎么做"。比如你要表达"先尝试用工具 A 处理，失败了再用工具 B 兜底，两次都失败就上报"，在命令式框架里你得写 try-catch 嵌套加状态标记；在 JAZ 这类语言里，这可能就是一行带 fallback 语义的声明。声明式的好处是，编排逻辑变得可读、可审查、可 diff——你一眼能看出这个 Agent 的行为边界在哪。

语言的第二优势是可组合。原语（Primitive）是最小单元，原语可以组合成更大的原语，大原语再组合成完整的 Harness。这种组合是结构化的，不是靠函数调用堆出来的。结构化组合意味着你可以对编排逻辑本身做静态分析——比如检查有没有死循环、有没有不可达分支、有没有资源泄漏。这是命令式代码很难做到的，因为命令式代码的控制流是运行时才确定的。

语言的第三优势是可移植。编排逻辑一旦从宿主语言里抽出来，它就不再绑定某个具体的运行时。同一套 Harness 描述，理论上可以编译到不同的执行引擎上——今天跑在本地，明天跑在分布式环境，后天换个模型供应商，编排层不用动。这对那些需要"Agent anywhere"（到处部署）的场景特别有价值。

2.3 原语设计：Primitive 的粒度怎么定

JAZ 里最值得琢磨的设计是Primitive 的粒度。粒度太细，比如把"加一"都做成原语，那编排逻辑会碎成一地，写起来比汇编还累；粒度太粗，比如把"完成一次完整的客服对话"做成一个原语，那又失去了组合的灵活性，等于把框架的坑换了个地方埋。

合理的粒度应该落在语义边界上。什么叫语义边界？就是这个操作有明确的输入输出契约，有独立的错误语义，有可观测的执行痕迹。比如"调用一次模型"是一个原语，因为它有明确的输入（prompt + 参数）和输出（文本 + token 消耗），失败模式清晰（超时、限流、内容过滤）。而"处理用户投诉"不是一个原语，因为它内部包含了太多可变逻辑，应该由多个原语组合而成。

我个人的经验是，原语的数量控制在十几个到几十个之间比较舒服。太少了不够用，太多了记不住。JAZ 目前暴露的原语集，从热词里能看出端倪——invoke 是核心动作原语，围绕它还有条件判断、循环、并发、错误处理、状态读写这几类。这个划分和大多数编排语言的设计是吻合的，说明它踩在了合理的工程经验上。

2.4 和现有方案的对比：JAZ 站在哪个位置

把 JAZ 放到现有的 Agent 编排方案光谱里看，会更清楚它的定位。

图编排（DAG）是前几年比较流行的思路，用节点和边描述流程。它的优点是直观，缺点是表达力天花板低——真实 Agent 的行为往往不是静态图能描述的，动态分支、递归、条件循环这些用图表达起来很别扭。JAZ 走语言路线，理论上表达力上限更高，代价是需要定义语法和语义，学习曲线更陡。

提示：选型时别只看表达力上限，还要看团队的学习成本和调试体验。语言类方案在可读性和可分析性上有优势，但调试工具链如果跟不上，排查问题会比命令式代码更痛苦。

3. invoke 与 Primitive：JAZ 的执行模型拆解

3.1 invoke 的语义：一次调用到底发生了什么

invoke是 JAZ 里最高频的动作原语，理解它的语义是理解整个执行模型的关键。一次 invoke 表面上是"调用某个东西"，但底下至少包含四件事：参数求值、目标解析、执行、结果处理。

参数求值阶段，JAZ 需要确定这次调用传什么参数。参数可能来自字面量、来自上游原语的输出、来自外部状态、来自环境变量。这里有个容易踩的坑：参数的求值时机。是调用前一次性求值，还是执行时才惰性求值？如果是惰性求值，那参数表达式里引用的状态在执行时可能已经变了。JAZ 的设计倾向于显式求值，也就是在 invoke 之前把参数算清楚，这样行为可预测，调试也容易。

目标解析阶段，JAZ 要确定"调用谁"。这个"谁"可能是一个工具、一个子 Harness、一个模型端点。解析过程可能涉及路由逻辑——比如根据输入类型选择不同的工具。路由逻辑本身也是编排的一部分，JAZ 把它做成可声明的，而不是藏在代码里。

执行阶段就是真正干活。这里的关键是执行语义：同步还是异步？阻塞还是非阻塞？超时怎么算？JAZ 作为编排语言，需要把这些语义显式化，而不是依赖宿主语言的默认行为。比如一个 invoke 默认是同步阻塞的，但你可以标注它为异步，让它返回一个 future 之类的句柄，后续再 await。

结果处理阶段决定这次调用的输出怎么进入下一步。是直接透传，还是做转换，还是只取其中一部分？JAZ 通常提供模式匹配或字段提取的语法，让你精确控制结果的流向。

3.2 Primitive 的组合规则：怎么把小块拼成大块

原语单独用没意义，价值在组合。JAZ 的组合规则，从设计上看遵循几条原则。

顺序组合是最基本的，前一个的输出喂给后一个的输入。但顺序组合有个隐含假设：数据流是线性的。真实场景里经常需要扇出（一个结果喂给多个下游）和扇入（多个结果汇聚成一个）。JAZ 需要提供对应的组合子来处理这些拓扑。

条件组合处理分支。if-else 是最简单的，但 Agent 场景里更常见的是守卫（guard）——满足条件才执行，不满足就跳过或走默认路径。守卫比 if-else 更声明式，因为它把"条件"和"动作"解耦了，条件可以独立测试和复用。

循环组合处理重复。Agent 里最常见的循环是"反复尝试直到成功或达到上限"，也就是重试循环。JAZ 如果把重试做成原语级的组合子，而不是让你手写 while，那编排逻辑会干净很多。重试的语义细节很多：退避策略、最大次数、哪些错误可重试、重试时状态怎么重置——这些都应该在组合子层面统一处理，而不是每个地方各写各的。

并发组合处理并行。多个独立的 invoke 可以并发执行，然后等所有结果。并发组合的难点在于错误处理——一个失败了，其他要不要取消？部分成功怎么算？JAZ 需要定义清晰的并发语义，否则用起来会踩坑。

3.3 状态管理：Harness 的记忆放在哪

Agent 有记忆，Harness 也得有状态。JAZ 里的状态管理，核心问题是状态存在哪、谁能读写、生命周期多长。

从粒度上分，状态至少有三个层次：单次 invoke 的局部状态（比如这次调用的中间结果）、单次 Harness 执行的会话状态（比如这次任务已经走了哪些步骤）、跨执行的持久状态（比如用户偏好、历史记录）。JAZ 需要为不同层次的状态提供不同的声明方式，而不是一股脑塞进一个全局字典。

局部状态最简单，作用域限于当前原语，执行完就丢。会话状态复杂一些，它需要在原语之间传递，但执行结束就清空。持久状态最麻烦，它涉及存储、序列化、并发访问、版本迁移。很多 Agent 项目在持久状态上翻车，就是因为早期图省事用了全局变量，后期想改成持久化发现到处都在读写，改不动。

JAZ 的设计如果够严谨，应该把状态的读写权限也纳入编排描述。哪些原语能读、哪些能写、写的时候要不要加锁——这些在并发场景下是必须显式声明的，否则会出现竞态。这一点在"AI Agent 怎么扛并发"这个热词里体现得很明显，说明大家已经被并发状态问题坑过了。

3.4 错误语义：失败不是异常，是流程的一部分

命令式代码里，错误处理靠异常。异常的问题是它打断了控制流，你得用 try-catch 把控制流接回来，接得不好就漏了或者吞了。JAZ 作为编排语言，更合理的做法是把失败建模成一等公民——失败是一种正常的结果，和成功并列，编排逻辑显式地处理这两种结果。

这意味着 invoke 的返回不是一个值，而是一个结果类型，可能是成功值，也可能是失败原因。后续的组合子根据结果类型决定走哪条路。这种建模方式的好处是，失败路径和成功路径一样可读、可测试、可组合。你可以在编排层面统一决定"失败三次就降级""特定错误就换工具""所有失败都记录到审计日志"，而不是在每个调用点重复写错误处理。

注意：把失败建模成结果类型，会让编排逻辑变长，因为每个 invoke 后面都得处理两种结果。JAZ 如果提供默认的失败传播语义（类似 Rust 的?操作符），能大幅减少样板代码。选型时要看它有没有这类语法糖。

4. 从 JAZ 看 Harness 工程：编排层该怎么工程化

4.1 Harness 工程和普通开发的区别

"Harness 工程"这个词最近被提得很多，但它和普通软件开发到底差在哪，很多人说不清。我的理解是，Harness 工程的核心挑战在于它编排的是不确定的东西。

普通软件开发，你调用的函数是确定的——给同样的输入，出同样的输出，失败模式也是有限的几种。Harness 编排的是模型调用和工具调用，这两者都不确定。模型可能这次答对下次答错，工具可能这次通下次超时。这种不确定性，让 Harness 工程必须把"应对不确定性"作为一等目标，而不是事后补丁。

具体到工程实践上，这意味着几件事。可观测性必须内建，不能事后加。你得知道每次执行走了哪条路径、每个原语的耗时、每次模型调用的 token 消耗、每次失败的具体原因。没有这些，你根本没法优化。可测试性必须设计进去，不能靠手动跑。编排逻辑要能在不调用真实模型的情况下测试，否则测试成本高到没人愿意写。可演进性必须考虑，因为模型和工具都在快速变化，编排逻辑得能跟着变而不推倒重来。

4.2 可观测性：编排逻辑的"行车记录仪"

JAZ 这类语言在可观测性上有个天然优势：编排逻辑是结构化的，所以执行轨迹也是结构化的。命令式代码的执行轨迹是一堆函数调用栈，你得靠日志拼凑出发生了什么；结构化编排的执行轨迹是一棵树或者一张图，每个节点对应一个原语，每条边对应一次数据流。这种结构化的轨迹，可以直接拿来做可视化、做分析、做告警。

具体要观测什么？至少这几样：路径（这次执行走了哪些原语）、耗时（每个原语花了多久，瓶颈在哪）、数据（每个原语的输入输出，用于复现问题）、异常（哪些原语失败了，失败原因是什么）。这四样凑齐，基本能覆盖大部分排查场景。

有个实操心得：观测数据的采样策略要早定。全量记录数据量太大，尤其是模型调用的输入输出可能很长。但采样太狠又会漏掉关键问题。我的做法是分层采样——路径和耗时全量记录（数据量小），数据按比例采样（比如 10%），异常全量记录。这样既能看全局，又能查个案。

4.3 可测试性：怎么在不烧钱的情况下测编排

Agent 测试最烧钱的地方是模型调用。每次测试都真调模型，成本高、速度慢、结果还不稳定。JAZ 这类编排语言，如果设计得当，可以让编排逻辑和模型调用解耦，从而支持 mock 测试。

解耦的关键是把模型调用也当成原语。既然它是原语，那就可以替换——测试时用一个 mock 原语替换真实原语，返回预设的结果。这样你测的是编排逻辑本身：条件分支走对没有、重试逻辑触发没有、状态传递正确没有。这些逻辑问题，用 mock 就能测出来，不需要真调模型。

编排逻辑的测试还应该覆盖边界情况：模型返回空结果怎么办、工具超时怎么办、并发时状态冲突怎么办。这些情况在真实环境里偶发，但一旦发生就是事故。用 mock 可以稳定复现这些边界，把它们变成常规测试用例。

4.4 版本管理：编排逻辑的演进策略

编排逻辑会变，而且会经常变。模型升级了要调 prompt，工具换了要改路由，业务需求变了要加分支。这些变化如果管理不好，会变成技术债。

JAZ 作为语言，在版本管理上有优势：编排逻辑是文本，文本就能 diff、能 review、能回滚。这比命令式代码里散落各处的逻辑好管理得多。但光有 diff 还不够，还需要语义化的版本管理——不只是看文本变了什么，还要看行为变了什么。

实操上，我建议给编排逻辑建立变更影响分析的习惯。改一个原语，要评估它影响哪些下游；改一个条件，要评估它改变了哪些路径。这种分析在结构化编排里是可行的，因为依赖关系是显式的。命令式代码里做这种分析，基本靠人肉读代码，容易漏。

5. 落地 JAZ 思路的实操路径：从概念到能跑

5.1 环境准备与最小可跑示例

假设你想在自己的项目里落地 JAZ 的思路，第一步不是去装什么工具，而是先把编排逻辑从业务代码里抽出来。这一步和具体用什么语言无关，是思维方式的转变。

具体做法：找一个你现有的 Agent 流程，把它画成图。节点是原语（模型调用、工具调用、条件判断、状态读写），边是数据流。画的过程中你会发现，很多逻辑其实是重复的——同样的重试、同样的错误处理、同样的状态读写。这些重复就是可以抽象成原语和组合子的地方。

抽出来之后，用伪代码或者简单的 DSL 描述这个流程。不用一上来就追求完整的语言实现，先用最朴素的方式把"声明式编排"的感觉找到。比如你可以用 YAML 或者 JSON 描述流程，然后写一个解释器去执行它。这个解释器不需要很强大，能跑通基本流程就行。

# 一个极简的编排描述示例 harness: name: customer_query steps: - id: classify invoke: model.classify input: "{{ user_input }}" output: category - id: route switch: "{{ category }}" cases: refund: - invoke: tool.refund_lookup input: "{{ user_input }}" technical: - invoke: tool.kb_search input: "{{ user_input }}" default: - invoke: model.general_reply input: "{{ user_input }}"

这个例子里，invoke是原语，switch是组合子，{{ }}是参数引用。整个描述是声明式的，读起来就是"先分类，再根据分类走不同路径"。这种描述可以直接被解释器执行，也可以被静态分析。

5.2 原语库的搭建顺序

落地 JAZ 思路，原语库的搭建顺序很关键。我的建议是从少到多，按需添加，而不是一开始就设计一套大而全的原语。

第一批原语，只需要覆盖最核心的动作：模型调用、工具调用、条件判断、状态读写。这四个能支撑起大部分简单流程。先用这四个跑通一个真实场景，感受一下声明式编排的优缺点。

第二批原语，根据实际痛点添加。常见的痛点包括：重试、超时控制、并发、结果转换、日志记录。这些如果每次都手写，会很烦，做成原语或组合子能大幅简化。

第三批原语，是那些特定领域的。比如做 RPA 落地，可能需要"操作浏览器""读取表格""发送通知"这类原语；做数据处理，可能需要"读取文件""转换格式""写入数据库"。这些原语和业务强相关，不适合放进通用库，应该按项目单独维护。

提示：原语库的维护成本不低，每个原语都要有清晰的契约、错误语义、测试用例。别为了"看起来完整"而堆原语，用不上的原语就是负债。

5.3 和现有 Agent 框架的集成方式

你大概率不是从零开始，而是已经用了某个 Agent 框架。JAZ 的思路可以和现有框架集成，不一定非要推倒重来。

集成方式有两种。一种是包裹式：把现有框架的调用封装成原语，编排层用 JAZ 思路描述，执行时调用框架。这样编排逻辑和框架实现解耦，将来换框架只改原语实现，编排描述不动。另一种是并存式：新流程用 JAZ 思路写，老流程保持原样，逐步迁移。这种方式风险小，但会有两套逻辑并存，维护成本高。

我倾向于包裹式，但前提是现有框架的调用接口足够清晰，能干净地封装成原语。如果框架的调用逻辑和业务代码搅在一起，封装起来会很痛苦，这时候可能得先做一轮重构。

5.4 并发场景下的编排注意事项

"AI Agent 怎么扛并发"是个高频问题，JAZ 这类编排语言在并发上有天然优势，但也有坑。

优势在于，并发逻辑可以声明式表达。哪些原语可以并行、并行度多少、失败怎么处理，这些都能在编排层统一描述，而不是散落在代码里。声明式并发的好处是可分析——你能静态看出哪些地方有并发、并发之间有没有共享状态、有没有死锁风险。

坑在于共享状态。并发执行时，多个原语可能同时读写同一个状态，产生竞态。JAZ 需要在编排层显式声明状态的访问模式，比如"这个状态只读""这个状态需要独占写"。如果语言层面不提供这种声明，你就得靠约定，而约定在并发场景下很容易被打破。

另一个坑是资源限制。并发度不是越高越好，模型调用有速率限制，工具调用有连接池限制。编排层需要感知这些限制，做背压控制。JAZ 如果提供资源声明和背压原语，能省很多事。

6. 我对 JAZ 这类方案的判断和实操建议

6.1 它适合什么样的团队和场景

JAZ 这类"Harness as a Language"的方案，不是万能药。它适合的场景有明确特征：编排逻辑复杂且多变、需要多人协作维护、对可观测性和可测试性有要求。如果你的 Agent 就是简单的一问一答，或者流程固定到几乎不会变，那用 JAZ 是杀鸡用牛刀，直接写代码更快。

团队方面，它适合有一定工程素养的团队。声明式编排、原语设计、组合子这些概念，需要团队成员理解并达成共识。如果团队里大部分人对"编排"没有概念，上来就用 JAZ，可能会水土不服——他们会觉得还不如直接写代码直观。

场景方面，它特别适合需要长期演进的 Agent 项目。一次性脚本怎么写都行，但一个要跑几年、要不断加功能、要多人维护的 Agent，编排层的工程质量就是生死线。JAZ 这类方案的价值，在长期项目里才能充分体现。

6.2 上手时最容易踩的三个坑

第一个坑是过度抽象。刚接触声明式编排，容易兴奋，想把所有东西都抽象成原语。结果原语库膨胀到几十上百个，每个原语用不了几次，维护成本却很高。我的建议是，原语只在被复用三次以上时才抽象，否则就内联在编排逻辑里。

第二个坑是忽视调试体验。声明式编排的可读性好，但调试体验往往不如命令式代码。命令式代码可以打断点、单步执行，声明式编排如果工具链跟不上，排查问题只能靠日志。上手前一定要确认调试工具链是否够用，否则遇到问题会很痛苦。

第三个坑是状态管理失控。前面提过，状态是编排层最容易出问题的地方。上手时就要建立状态管理的规范：哪些状态放哪一层、谁能读写、生命周期多长。别等到状态乱成一锅粥再回头治理，那时候改造成本高得吓人。

6.3 后续可以怎么扩展

JAZ 的思路可以往几个方向扩展。一是编排逻辑的静态分析，既然编排是结构化的，就可以做类型检查、死代码检测、资源泄漏检测。这些在命令式代码里要靠复杂工具，在结构化编排里可以做得更轻量。二是编排逻辑的可视化，结构化的编排天然适合画成图，可视化编辑器能降低上手门槛。三是编排逻辑的自动优化，比如自动识别可并行的部分、自动插入重试和降级、自动做资源调度。

这些扩展方向，有些 JAZ 可能已经在做，有些还需要生态慢慢补。作为使用者，我的建议是先关注核心价值——声明式编排带来的可读性、可组合性、可分析性。这些是 JAZ 的立身之本，其他都是锦上添花。

最后分享一个我自己的体会：编排层的工程质量，往往决定了 Agent 项目能走多远。模型能力会涨，工具会换，但编排逻辑是那个把一切串起来的东西。把它当成一等公民来对待，用合适的语言和工具去表达它，长期看是值得的投入。JAZ 提供了一个值得参考的方向，至于要不要全盘采用，得看你的具体场景和团队情况——但至少，它让你意识到"Harness 本身值得被认真设计"这件事，这已经很有价值了。