{"schema_version":1,"id":"article:agent-infra-three-layers","kind":"article","slug":"agent-infra-three-layers","title":"从驾驭模型到可靠行动：我对 Agent Infra 的阶段性理解","author":"晨旭","url":"https://chenxu.xin/writing/agent-infra-three-layers","date":"2026-08-24","updated":"2026-08-24","description":"与其按功能分层，不如按「保证」分层。一个用事实源作用域来切分 Harness 层、控制层、治理层的工作模型，以及它能解释什么、可能在哪里出错。","position":null,"group":null,"series":"AI技术理解","tags":["agent"],"publication_status":"public","maturity":"seed","body_sha256":"8fef3a663f516ce82806b6e763e2bc826a9dce1d322da6b71370a17c12ba13e5","paragraph_rule":"src/lib/paragraphs.mjs@1","paragraphs":[{"id":"p1","kind":"paragraph","text":"这不是一篇试图给 Agent Infra 下标准定义的技术科普文章。它源于我学习 Harness Engineering、研究 DeepSeek Harness，并尝试探索 Agent Infra 时产生的一系列困惑。","raw":"这不是一篇试图给 Agent Infra 下标准定义的技术科普文章。它源于我学习 Harness Engineering、研究 DeepSeek Harness，并尝试探索 Agent Infra 时产生的一系列困惑。"},{"id":"p2","kind":"paragraph","text":"下面不是宣布 Agent Infra 就应该这样分，而是提出一个暂时能够帮助我理解这些概念的工作模型：它从哪里来、可以解释什么，以及可能在哪里出错。","raw":"下面不是宣布 Agent Infra 就应该这样分，而是提出一个暂时能够帮助我理解这些概念的工作模型：它从哪里来、可以解释什么，以及可能在哪里出错。"},{"id":"p3","kind":"heading","text":"为什么 Agent Infra 越看越模糊","raw":"## 为什么 Agent Infra 越看越模糊"},{"id":"p4","kind":"paragraph","text":"LLM Infra 的边界相对清楚。它研究如何训练、部署和服务大模型，包括分布式训练、模型并行、推理调度、Prefill、Decode、KV Cache、吞吐和延迟。简单来说，它关心的是：如何更快、更便宜、更稳定地产生 Token。","raw":"LLM Infra 的边界相对清楚。它研究如何训练、部署和服务大模型，包括分布式训练、模型并行、推理调度、Prefill、Decode、KV Cache、吞吐和延迟。简单来说，它关心的是：如何更快、更便宜、更稳定地产生 Token。"},{"id":"p5","kind":"paragraph","text":"但 Agent Infra 并没有类似的共识：","raw":"但 Agent Infra 并没有类似的共识："},{"id":"p6","kind":"list","text":"- 在一些行业文章里，Agent Infra 是由模型、记忆、知识检索、工具、编排、沙箱和可观测性组成的技术栈。\n- 在 DeepSeek Harness 中，Harness 主要指模型周围的运行环境：如何组装上下文、注册工具、记录 Session、管理权限和执行 Agent Loop。\n- 而在我最近学习的一些 Harness Engineering 中，重点却是 Run API、状态机、数据库、队列、Outbox、Worker、租约、幂等和故障恢复。\n- Chan 等人在论文《Infrastructure for AI Agents》中讨论的又是另一类问题：如何将 Agent 的行为归因到具体的人或组织，如何规范 Agent 之间的交互，以及如何发现和补救有害行为。","raw":"- 在一些行业文章里，Agent Infra 是由模型、记忆、知识检索、工具、编排、沙箱和可观测性组成的技术栈。\n- 在 DeepSeek Harness 中，Harness 主要指模型周围的运行环境：如何组装上下文、注册工具、记录 Session、管理权限和执行 Agent Loop。\n- 而在我最近学习的一些 Harness Engineering 中，重点却是 [Run API、状态机、数据库](/writing/agent-harness-run-api)、队列、Outbox、Worker、租约、幂等和故障恢复。\n- Chan 等人在论文《Infrastructure for AI Agents》中讨论的又是另一类问题：如何将 Agent 的行为归因到具体的人或组织，如何规范 Agent 之间的交互，以及如何发现和补救有害行为。"},{"id":"p7","kind":"paragraph","text":"它们似乎都在讨论 Agent Infra，却明显不在同一个尺度上。常见的架构图可以告诉我「系统中有哪些组件」，但很难回答下面这些问题：","raw":"它们似乎都在讨论 Agent Infra，却明显不在同一个尺度上。常见的架构图可以告诉我「系统中有哪些组件」，但很难回答下面这些问题："},{"id":"p8","kind":"list","text":"- 审批属于 Harness、编排还是治理？\n- Session Log 属于记忆还是可观测？\n- Token 计费属于 LLM Infra 还是 Agent 平台？\n- SSE 实时事件流到底属于哪一层？\n- 为什么幂等不能只在 Worker 内部实现？","raw":"- 审批属于 Harness、编排还是治理？\n- Session Log 属于记忆还是可观测？\n- Token 计费属于 LLM Infra 还是 Agent 平台？\n- SSE 实时事件流到底属于哪一层？\n- 为什么幂等不能只在 Worker 内部实现？"},{"id":"p9","kind":"paragraph","text":"这些问题让我意识到：也许「某个功能属于哪一层」本身就是错误的提问方式。","raw":"这些问题让我意识到：也许「某个功能属于哪一层」本身就是错误的提问方式。"},{"id":"p10","kind":"heading","text":"与其按照功能分层，不如按照保证分层","raw":"## 与其按照功能分层，不如按照保证分层"},{"id":"p11","kind":"paragraph","text":"审批、计费、超时、事件流，都是功能名称。一个功能通常同时包含多条性质完全不同的保证。例如，审批至少可能包含两件事：","raw":"审批、计费、超时、事件流，都是功能名称。一个功能通常同时包含多条性质完全不同的保证。例如，审批至少可能包含两件事："},{"id":"p12","kind":"list","text":"1. 模型调用高风险工具前，当前进程弹出一个确认框；\n2. 即使进程崩溃，任务重启后仍然停留在等待审批的状态。","raw":"1. 模型调用高风险工具前，当前进程弹出一个确认框；\n2. 即使进程崩溃，任务重启后仍然停留在等待审批的状态。"},{"id":"p13","kind":"paragraph","text":"第一条只需要当前执行环境知道审批结果，第二条则要求审批状态被持久保存，并能被其他 Worker 重新读取。它们虽然都叫审批，需要的基础设施却不同。","raw":"第一条只需要当前执行环境知道审批结果，第二条则要求审批状态被持久保存，并能被其他 Worker 重新读取。它们虽然都叫审批，需要的基础设施却不同。"},{"id":"p14","kind":"paragraph","text":"因此，我目前尝试使用这样一个判据：","raw":"因此，我目前尝试使用这样一个判据："},{"id":"p15","kind":"quote","text":"不要先问一个功能属于哪一层，而要先把它拆成一条条保证，再看每条保证成立所需的最小事实源作用域。","raw":"> 不要先问一个功能属于哪一层，而要先把它拆成一条条保证，再看每条保证成立所需的最小事实源作用域。"},{"id":"p16","kind":"paragraph","text":"这里的「事实源」，指的是系统判断某件事是否成立时，最终相信的那份记录。例如：","raw":"这里的「事实源」，指的是系统判断某件事是否成立时，最终相信的那份记录。例如："},{"id":"p17","kind":"list","text":"- 「模型这一步看到了哪些上下文」可能由当前 Session Log 决定；\n- 「这笔退款是否已经执行」必须由所有 Worker 共同访问的幂等记录决定；\n- 「这个 Agent 的行为是否能归因到某个法人」则需要信任域之外也认可的身份和审计体系。","raw":"- 「模型这一步看到了哪些上下文」可能由当前 Session Log 决定；\n- 「这笔退款是否已经执行」必须由所有 Worker 共同访问的幂等记录决定；\n- 「这个 Agent 的行为是否能归因到某个法人」则需要信任域之外也认可的身份和审计体系。"},{"id":"p18","kind":"paragraph","text":"按照事实源需要覆盖的范围，我暂时把 Agent Infra 理解为三个领域。","raw":"按照事实源需要覆盖的范围，我暂时把 Agent Infra 理解为三个领域。"},{"id":"p19","kind":"heading","text":"我的三层工作模型","raw":"## 我的三层工作模型"},{"id":"p20","kind":"heading","text":"1、Harness 层：模型如何完成一次行动","raw":"### 1、Harness 层：模型如何完成一次行动"},{"id":"p21","kind":"paragraph","text":"Harness 层位于模型和环境之间，负责模型直接参与的执行语义。它回答的问题是：这一步给模型什么上下文？模型可以看到哪些工具？工具参数和返回结果以什么格式呈现？模型调用工具后，结果怎样进入下一轮上下文？Agent Loop 何时继续、停止或请求确认？","raw":"Harness 层位于模型和环境之间，负责模型直接参与的执行语义。它回答的问题是：这一步给模型什么上下文？模型可以看到哪些工具？工具参数和返回结果以什么格式呈现？模型调用工具后，结果怎样进入下一轮上下文？Agent Loop 何时继续、停止或请求确认？"},{"id":"p22","kind":"paragraph","text":"SWE-agent 提出的 ACI（Agent-Computer Interface）说明，工具接口并不是模型外面无关紧要的包装。文件一次展示多少行、搜索结果是否过长、编辑失败如何反馈，都会显著改变 Agent 的行为。","raw":"SWE-agent 提出的 ACI（Agent-Computer Interface）说明，工具接口并不是模型外面无关紧要的包装。文件一次展示多少行、搜索结果是否过长、编辑失败如何反馈，都会显著改变 Agent 的行为。"},{"id":"p23","kind":"paragraph","text":"所以我把上下文装配、工具 ACI、Session、技能、Agent Loop 和局部沙箱等内容放在 Harness 层。","raw":"所以我把上下文装配、工具 ACI、Session、技能、Agent Loop 和局部沙箱等内容放在 Harness 层。"},{"id":"p24","kind":"paragraph","text":"不过，事实源作用域在这里更像一个辅助判据，而不是完整定义。并不是所有进程内状态都属于 Harness，例如 SSE 连接也是进程内状态，但它并不参与模型执行。因此更准确的说法是：Harness 负责模型参与的执行语义，其中许多保证只需要在当前执行域内成立。","raw":"不过，事实源作用域在这里更像一个辅助判据，而不是完整定义。并不是所有进程内状态都属于 Harness，例如 SSE 连接也是进程内状态，但它并不参与模型执行。因此更准确的说法是：Harness 负责模型参与的执行语义，其中许多保证只需要在当前执行域内成立。"},{"id":"p25","kind":"heading","text":"2、控制层：多个执行者如何可靠地完成同一个任务","raw":"### 2、控制层：多个执行者如何可靠地完成同一个任务"},{"id":"p26","kind":"paragraph","text":"当系统只有一个进程时，它可以在内存中记住「我做过什么」。但只要引入多 Worker、重试和故障接管，很多问题就无法再由单个执行者回答。","raw":"当系统只有一个进程时，它可以在内存中记住「我做过什么」。但只要引入多 Worker、重试和故障接管，很多问题就无法再由单个执行者回答。"},{"id":"p27","kind":"paragraph","text":"以幂等为例。在「至少一次投递」的系统中，同一个任务可能被重复交给不同 Worker。如果要保证退款不会执行两次，那么「这笔退款做过吗」的答案就必须满足：当前 Worker 崩溃后仍然存在、其他 Worker 能够读取、多个 Worker 同时操作时能够原子裁决。","raw":"以幂等为例。在「至少一次投递」的系统中，同一个任务可能被重复交给不同 Worker。如果要保证退款不会执行两次，那么「这笔退款做过吗」的答案就必须满足：当前 Worker 崩溃后仍然存在、其他 Worker 能够读取、多个 Worker 同时操作时能够原子裁决。"},{"id":"p28","kind":"paragraph","text":"因此，幂等记录不可能只存在某个 Worker 的内存里。它需要数据库事务、唯一约束、原子 Compare-and-Swap 或外部系统的幂等协议。同样，状态机、租约、执行权、持久事件、配额和租户账本都需要跨执行者共享的事实源。","raw":"因此，幂等记录不可能只存在某个 Worker 的内存里。它需要数据库事务、唯一约束、原子 Compare-and-Swap 或外部系统的幂等协议。同样，状态机、租约、执行权、持久事件、配额和租户账本都需要跨执行者共享的事实源。"},{"id":"p29","kind":"paragraph","text":"我把这些能力放在控制层。这一层回答的是：谁可以执行、任务现在在哪里、失败后由谁接管，以及某个副作用是否已经发生。","raw":"我把这些能力放在控制层。这一层回答的是：谁可以执行、任务现在在哪里、失败后由谁接管，以及某个副作用是否已经发生。"},{"id":"p30","kind":"paragraph","text":"市面上类似 Temporal 的持久化运行，也主要解决这一层的问题：持久化的不只是数据，而是一次运行在崩溃后继续推进的能力。","raw":"市面上类似 Temporal 的持久化运行，也主要解决这一层的问题：持久化的不只是数据，而是一次运行在崩溃后继续推进的能力。"},{"id":"p31","kind":"heading","text":"3、治理层：系统之外的人为什么可以相信它","raw":"### 3、治理层：系统之外的人为什么可以相信它"},{"id":"p32","kind":"paragraph","text":"控制层解决的是「我们的多个进程如何达成一致」，治理层解决的则是：不受我们控制、也不天然信任我们的人，为什么应该相信这条记录？","raw":"控制层解决的是「我们的多个进程如何达成一致」，治理层解决的则是：不受我们控制、也不天然信任我们的人，为什么应该相信这条记录？"},{"id":"p33","kind":"paragraph","text":"例如，将某次 Agent 行为归因到特定用户或法人，仅仅在自己的数据库中写入一个 user_id 并不充分。数据库只能证明「我们的系统这样记录了」，不能自动让交易对手、监管者或审计机构相信这条记录真实可靠。这时需要的工具会发生变化：数字签名、身份协议、证书、可验证凭证、第三方审计和法律责任体系开始出现。","raw":"例如，将某次 Agent 行为归因到特定用户或法人，仅仅在自己的数据库中写入一个 `user_id` 并不充分。数据库只能证明「我们的系统这样记录了」，不能自动让交易对手、监管者或审计机构相信这条记录真实可靠。这时需要的工具会发生变化：数字签名、身份协议、证书、可验证凭证、第三方审计和法律责任体系开始出现。"},{"id":"p34","kind":"paragraph","text":"这里的边界不是「是否跨组织」。例如，调用 Stripe 时使用 Idempotency-Key 虽然跨越了两家公司，但本质上仍然是双方约定的 API 契约。只有当某项事实需要被信任域外的第三方验证时，它才真正进入我所说的治理层。","raw":"这里的边界不是「是否跨组织」。例如，调用 Stripe 时使用 Idempotency-Key 虽然跨越了两家公司，但本质上仍然是双方约定的 API 契约。只有当某项事实需要被信任域外的第三方验证时，它才真正进入我所说的治理层。"},{"id":"p35","kind":"paragraph","text":"因此，这三层分别对应三种不同的问题：","raw":"因此，这三层分别对应三种不同的问题："},{"id":"p36","kind":"code","text":"Harness：模型怎样行动？\n控制层：多个执行者怎样共同完成任务？\n治理层：系统之外的人为什么可以相信这些行为？","raw":"```text\nHarness：模型怎样行动？\n控制层：多个执行者怎样共同完成任务？\n治理层：系统之外的人为什么可以相信这些行为？\n```"},{"id":"p37","kind":"paragraph","text":"LLM Infra 则位于 Model Call 的另一侧：Agent Infra 发送 Prompt，LLM Infra 返回 Token。前者关心任务能否完成，后者主要关心模型如何高效运行。","raw":"LLM Infra 则位于 Model Call 的另一侧：Agent Infra 发送 Prompt，LLM Infra 返回 Token。前者关心任务能否完成，后者主要关心模型如何高效运行。"},{"id":"p38","kind":"heading","text":"用 SSE 检验这张地图","raw":"## 用 SSE 检验这张地图"},{"id":"p39","kind":"paragraph","text":"「SSE 实时事件流属于哪一层」是一个很好的测试题，因为 SSE 看起来是一个功能，实际却包含多个承诺：","raw":"「SSE 实时事件流属于哪一层」是一个很好的测试题，因为 SSE 看起来是一个功能，实际却包含多个承诺："},{"id":"p40","kind":"list","text":"1. 快：事件发生后尽快出现在页面上；\n2. 全：断线期间发生的事件不能永久丢失；\n3. 有序：客户端看到的顺序与系统确认的顺序一致；\n4. 能续：重连后能够从上次位置继续读取。","raw":"1. **快**：事件发生后尽快出现在页面上；\n2. **全**：断线期间发生的事件不能永久丢失；\n3. **有序**：客户端看到的顺序与系统确认的顺序一致；\n4. **能续**：重连后能够从上次位置继续读取。"},{"id":"p41","kind":"paragraph","text":"「快」可以依靠 SSE 进程的内存连接和实时通知完成。连接断开后，浏览器重新建立连接即可，它不需要成为系统的永久事实源。","raw":"「快」可以依靠 SSE 进程的内存连接和实时通知完成。连接断开后，浏览器重新建立连接即可，它不需要成为系统的永久事实源。"},{"id":"p42","kind":"paragraph","text":"但「全」和「有序」不能只依靠推送通道。SSE 进程可能崩溃，客户端也可能被负载均衡到另一台服务器。如果仍要保证事件不丢，就必须把事件写入所有执行者都能访问的持久账本，并为每条事件分配稳定的 sequence。","raw":"但「全」和「有序」不能只依靠推送通道。SSE 进程可能崩溃，客户端也可能被负载均衡到另一台服务器。如果仍要保证事件不丢，就必须把事件写入所有执行者都能访问的持久账本，并为每条事件分配稳定的 sequence。"},{"id":"p43","kind":"paragraph","text":"「能续」则依靠客户端游标和持久账本之间的配合：","raw":"「能续」则依靠客户端游标和持久账本之间的配合："},{"id":"p44","kind":"code","text":"客户端：我已经看到 sequence = 4\n服务端：从持久账本补发 5、6、7……","raw":"```text\n客户端：我已经看到 sequence = 4\n服务端：从持久账本补发 5、6、7……\n```"},{"id":"p45","kind":"paragraph","text":"可以把它理解为直播和官方比赛记录：实时推送像直播，允许卡顿；持久事件账本像官方比分，不能丢失。断线后不是从直播信号里找回过去，而是先根据官方记录补齐，再重新回到直播。","raw":"可以把它理解为直播和官方比赛记录：实时推送像直播，允许卡顿；持久事件账本像官方比分，不能丢失。断线后不是从直播信号里找回过去，而是先根据官方记录补齐，再重新回到直播。"},{"id":"p46","kind":"paragraph","text":"因此，SSE 本身并不属于某一个单独层级——实时连接是局部传输机制，不丢和有序依赖控制层账本，断线续传是客户端游标与控制层之间的协议。","raw":"因此，SSE 本身并不属于某一个单独层级——实时连接是局部传输机制，不丢和有序依赖控制层账本，断线续传是客户端游标与控制层之间的协议。"},{"id":"p47","kind":"paragraph","text":"这也验证了前面的判断：功能名称经常横跨多个作用域，真正能够分层的是它所承诺的每一条保证。","raw":"这也验证了前面的判断：功能名称经常横跨多个作用域，真正能够分层的是它所承诺的每一条保证。"},{"id":"p48","kind":"heading","text":"把我接触到的系统放回地图","raw":"## 把我接触到的系统放回地图"},{"id":"p49","kind":"paragraph","text":"按照这张暂定地图，我目前这样理解几个相关概念：","raw":"按照这张暂定地图，我目前这样理解几个相关概念："},{"id":"p50","kind":"list","text":"- DeepSeek Harness 主要位于 Harness 层，重点是上下文、工具、Session、沙箱以及插件化的 Agent Runtime。\n- Harness Engineering 那一系列讨论主要位于控制层，重点是 Run、状态机、Outbox、队列、租约、幂等和故障恢复。\n- Temporal 等可以看作控制层的 Durable Execution 基础设施。\n- Chan 等人的 Agent Infrastructure 论文更接近治理层，重点是归因、交互协议和有害行为补救。","raw":"- **DeepSeek Harness** 主要位于 Harness 层，重点是上下文、工具、Session、沙箱以及插件化的 Agent Runtime。\n- **Harness Engineering** 那一系列讨论主要位于控制层，重点是 Run、状态机、Outbox、队列、租约、幂等和故障恢复。\n- **Temporal** 等可以看作控制层的 Durable Execution 基础设施。\n- **Chan 等人的 Agent Infrastructure 论文**更接近治理层，重点是归因、交互协议和有害行为补救。"},{"id":"p51","kind":"paragraph","text":"这些坐标不是对系统的完整定义。一套真实产品完全可以同时跨越多层，我只是标出了它最主要解决的问题。","raw":"这些坐标不是对系统的完整定义。一套真实产品完全可以同时跨越多层，我只是标出了它最主要解决的问题。"},{"id":"p52","kind":"heading","text":"最后","raw":"## 最后"},{"id":"p53","kind":"paragraph","text":"这套三层模型目前只是我的阶段性理解，至少还有几个尚未解决的问题：","raw":"这套三层模型目前只是我的阶段性理解，至少还有几个尚未解决的问题："},{"id":"p54","kind":"paragraph","text":"第一，事实源作用域更适合判断一条可靠性保证应该锚在哪里，却未必足以定义完整的架构职责。「进程内」不必然等于 Harness，「跨进程」也不必然都是 Agent 控制逻辑。","raw":"第一，事实源作用域更适合判断一条可靠性保证应该锚在哪里，却未必足以定义完整的架构职责。「进程内」不必然等于 Harness，「跨进程」也不必然都是 Agent 控制逻辑。"},{"id":"p55","kind":"paragraph","text":"第二，现实中的作用域未必只有三个离散等级。单机多进程、同一集群、多云和跨组织之间，可能存在连续变化的信任范围。","raw":"第二，现实中的作用域未必只有三个离散等级。单机多进程、同一集群、多云和跨组织之间，可能存在连续变化的信任范围。"},{"id":"p56","kind":"paragraph","text":"第三，Harness 与控制层也不是完全隔离的。审批、超时、取消和 Session 都可能在本地执行，同时由控制层持久化和裁决。","raw":"第三，Harness 与控制层也不是完全隔离的。审批、超时、取消和 Session 都可能在本地执行，同时由控制层持久化和裁决。"},{"id":"p57","kind":"paragraph","text":"但它目前对我最大的帮助，是把一个含糊的问题「这个功能属于哪一层？」改写成两个更具体的问题：","raw":"但它目前对我最大的帮助，是把一个含糊的问题「这个功能属于哪一层？」改写成两个更具体的问题："},{"id":"p58","kind":"list","text":"- 它要保证什么不出错？\n- 为了做到这一点，谁必须看到并认可同一条记录？","raw":"- 它要保证什么不出错？\n- 为了做到这一点，谁必须看到并认可同一条记录？"}],"authored_claims":[{"id":"wrong-question-which-layer","text":"「某个功能属于哪一层」本身可能就是错误的提问方式。审批、计费、超时、事件流都只是功能名称，一个功能通常同时包含多条性质完全不同的保证。","stance":"judgment","confidence":"high","supersedes":null,"note":null,"formed_at":"2026-08-24"},{"id":"layer-by-guarantee-not-function","text":"我目前的判据是：不要先问一个功能属于哪一层，而要先把它拆成一条条保证，再看每条保证成立所需的最小事实源作用域。","stance":"hypothesis","confidence":"medium","supersedes":null,"note":null,"formed_at":"2026-08-24"},{"id":"three-layers-three-questions","text":"三层分别对应三种问题——Harness 关心模型怎样行动，控制层关心多个执行者怎样共同完成任务，治理层关心系统之外的人为什么可以相信这些行为。","stance":"hypothesis","confidence":"medium","supersedes":null,"note":null,"formed_at":"2026-08-24"},{"id":"idempotency-cannot-live-in-worker","text":"幂等记录不可能只存在某个 Worker 的内存里。它必须在当前 Worker 崩溃后仍然存在、能被其他 Worker 读取、并在多个 Worker 同时操作时原子裁决，因此必然属于跨执行者共享的事实源。","stance":"fact","confidence":"high","supersedes":null,"note":null,"formed_at":"2026-08-24"},{"id":"governance-boundary-is-not-cross-org","text":"治理层的边界不是「是否跨组织」。调用 Stripe 时用 Idempotency-Key 虽然跨了两家公司，本质上仍是双方约定的 API 契约；只有当某项事实需要被信任域外的第三方验证时，它才真正进入治理层。","stance":"judgment","confidence":null,"supersedes":null,"note":null,"formed_at":"2026-08-24"}],"claim_ids":["wrong-question-which-layer","layer-by-guarantee-not-function","three-layers-three-questions","idempotency-cannot-live-in-worker","governance-boundary-is-not-cross-org"],"revision":"c4c04add15391d6966bff0ec562b027d9846e270fa6659de03c04299a2861009"}