Maka 超越函数调用：Agent 如何触达真实世界——Deferred Tools、可靠执行与可分解状态的运行时工程实践

Maka 超越函数调用：Agent 如何触达真实世界——Deferred Tools、可靠执行与可分解状态的运行时工程实践

【免费下载链接】makaApache Maka (Incubating) is a high-performance agent workspace that keeps a complete record of everything it did.项目地址: https://gitcode.com/GitHub_Trending/mak/maka

导读：本文以 Apache Maka (Incubating) 运行时架构为核心，系统拆解 Agent 工具调用从"模型提案"到"系统副作用"的完整链路。你将掌握：Deferred Tools 如何压缩上下文中的工具 schema 开销、T1/T2 两阶段持久化如何支撑崩溃恢复、Code Mode 如何把线性调用折叠为可审计的调用树、并行工具执行如何解耦并发与资源权威，以及基于不可变事件日志的 Serverless Agent 状态分解模型。全部结论均可对照仓库源码与测试用例验证。

工具不是免费的：一个从未被调用的工具也在持续消耗 Token

在传统程序中，一个未被调用的函数几乎不产生运行时开销：它可以安静地躺在源码仓库或动态链接库里，不占用 CPU 周期，也不占据栈帧。

Agent 架构中的工具（Tool）则截然不同。在大语言模型能够调用工具之前，运行时必须在每次请求中把工具名、行为描述和结构化参数 schema 随系统提示词、对话历史一并传输给模型。因此，即便某个工具在整个会话中从未被触发，它的 schema 也会在每一次推理步骤中持续消耗输入 Token。

Maka 称之为Deferred Tools（延迟工具）机制。它不改变执行时机，只控制"完整 schema 何时对模型可见"。相关实现在 packages/runtime/src/tool-availability.ts：运行时持续保留当前 run 中所有已注册的工具绑定（binding），但初始请求只暴露高频原语，外加一个紧凑的tool_search检索工具；扩展工具仅以名称和类别登记在轻量级清单（lightweight inventory）中，省略完整描述与参数 schema。

Bound Tool Registry │ ├──── Direct Tools ───────────────→ Full schemas in this request │ └──── Deferred Tools │ └──── Lightweight Search Inventory │ tool_search │ Bounded matches │ ▼ Next provider step injects matched schemas

三级工具状态：Bound / Discoverable / Visible

Maka 把工具状态组织为三个层次：

• Bound（已绑定）：运行时持有可执行实现，定义了本次 run 的绝对能力上限（capability ceiling）；
• Discoverable（可发现）：工具登记在轻量级清单中，让模型"知道它存在"；
• Visible（可见）：完整 schema 被注入当前 provider 请求，模型可以构造合法调用。

能力发现不会引入未注册的实现，也不会突破绑定上限，它只负责重塑后续推理步骤中呈现给模型的工具投影（tool projection）。

时间边界与回合作用域：不可追溯、不可累积

Deferred Tools 在源码层面严格实施了两条边界：

1. 步骤边界不可变：一旦 provider 步骤发出，其 schema 集合即不可变。如果模型在单次 completion 中生成如下序列：

tool_search("browser click") browser_click(...)

Maka 会拒绝第二次调用。tool_search的结果只作用于后续的 provider 交互，不能追溯修改已提交给 provider 的 schema；browser_click的完整定义会在下一步进入上下文。

2. 回合作用域严格隔离：延迟激活仅限当前 turn 有效，turn 内的重试会让已发现工具单调累积，turn 结束后释放；新用户 turn 会重置回基线工具集，防止零散使用长期污染推理上下文。

tool_search的默认激活上限是 8 个候选（TOOL_SEARCH_DEFAULT_LIMIT = 8，见 packages/runtime/src/tool-availability.ts），匹配针对工具名称、描述与功能类别进行，返回有界候选集。值得注意的是，完整 schema 从不直接灌入工具结果载荷——payload 只包含被激活的工具标识符，schema 通过标准工具投影注入下一个模型回合。另外 Maka 为 provider 保留了安全别名maka_tool_search（TOOL_SEARCH_PROVIDER_NAME），以规避 OpenAI Responses API 对tool_search的保留字冲突（同文件 L31-L33）。

可见不等于授权。一个可见的 schema 在调用时仍然要经过参数校验、并发检查和权限门控。tool_search调节的是"认知表面积"，系统安全始终由运行时强制执行——这是 Deferred Tools 设计的边界：约束呈现给模型的行动空间，同时完整保留运行时能力。

行动边界：从概率到系统副作用的桥

把工具 schema 注入上下文，只让模型"知道"有哪些行动可用。在模型产出工具调用之前，交互严格停留在文本 Token 领域。

大语言模型无法直接操控宿主机。它们消费输入序列、预测后续 Token——即使模型输出"我已更新配置文件"这句话，磁盘上也不会多出一个字节。描述性语言与具体系统状态之间隔着一道物理边界。

工具调用正是跨越这道边界的桥梁：模型停止自由文本生成，转而发射一个结构化的动作意图（action intent），包含目标工具、调用参数和关联标识符（Call ID）。运行时拦截该意图，在沙箱环境中执行真实操作，再把观测到的结果返回给模型：

LLM │ │ function_call(name, arguments, call_id) ▼ Runtime │ ├── Resolve tool binding ├── Validate arguments and execution bounds ├── Request required permissions ├── Invoke concrete system operation ▼ Filesystem / Process / Browser / Network / Human │ │ function_response(call_id, result) ▼ Next LLM inference step

这个闭环让模型得以与外环境交互：文件读取检查工作区状态，命令执行捕获编译器和测试诊断，文件修改更新工作树，网络调用对接外部服务，用户交互工具则暂停等待澄清。一个端到端的 Agent 步骤是"推理—行动—观测—推理"（Reason → Act → Observe → Reason）的完整闭环。

与传统函数调用的本质区别

常规软件在确定性执行环境中链接调用者与被调用者；而 LLM 产出的工具调用是概率性的动作提案——参数可能畸形、环境前置条件可能过期、对系统状态的假设可能错误。因此：

• 模型只拥有提案权（proposal authority）：产出语法合法的 JSON 并不能获得环境特权；
• 工具 schema 定义了提案的线格式，绑定注册了可用能力，运行时权限仲裁单个调用；
• 调用必须通过严格验证才能派发：绑定检查、turn 可见性校验、参数 schema 强制、并发策略应用，全部通过后底层系统实现才执行。

Call ID：审计与重放的锚点

执行完成后，运行时把外部载荷规范化为 provider 无关的工具结果，并通过稳定的 Call ID 配对。在 Maka 的RuntimeEvent Log中，这些事件以不可变的function_call与function_response条目提交，构成可审计、可重放、可崩溃恢复的事实基础（实现见 packages/runtime/src/tool-runtime.ts，其中function_call/function_response事件的构造分别在commitToolPrepared与commitToolOutcome路径上）。

Call ID 还是架构锚点：当 Agent 并发派发多个调用时，不同 I/O 延迟会打乱完成顺序。运行时依赖确定性标识符把结果路由回各自的因果链，并在重放时保持结构拓扑不变。

可靠执行：在已提交历史上做崩溃恢复

引入外部副作用，意味着 Agent 运行时必须直面真实世界的基础设施故障。

考虑这样一个场景：模型调用Edit把端口从3000改为4000，磁盘写入完成，但宿主进程随即断电。重启后，运行时观测到一个没有对应结果的悬空调用（dangling call）。这个缺失并不意味着文件系统未被触碰——缺失结果可能对应多种互相冲突的状态：调用从未派发、执行仍在进行、磁盘写入成功但元数据提交失败、或外部进程在写后修改了状态。盲目重放这类调用，可能造成重复写入、重复交易或持久数据损坏。

Maka 的答案是把每次外部工具调用包裹进一个轻量级的两阶段持久化边界：

Model generates function_call │ ▼ Validate parameters, visibility, permissions, and bounds │ ▼ T1: Commit Tool Dispatch │ ▼ Execute real-world operation │ ▼ T2: Commit function_response │ ▼ Deliver Tool Result to model

• T1（Tool Dispatch 提交）：代表所有预检通过、执行跨过派发阈值。从此刻起，运行时不能再安全地假设操作"从未发生"。T1 必须在具体实现被调用前提交；若 T1 持久化失败，外部动作保持阻断。
• T2（function_response 提交）：认证执行结果已作为不可变事件提交。只有 T2 提交后，结果才能进入后续模型推理步骤。即使外部操作成功，缺少 T2 持久化也禁止把未经核实的状态喂进活跃推理循环。

Maka不引入跨外部系统的分布式数据库事务——文件 I/O、shell 任务、浏览器驱动、网络请求的延迟差异巨大，全局 ACID 事务不切实际。它用两个局部存储事务把外部副作用窗口收紧为：

Committed T1 → External Side Effect → Committed T2

崩溃发生时，恢复逻辑从 append-only 事件前缀推导精确状态：

T1 与 T2 之间的区间是关键失败窗口：系统知道派发已获授权，但无法确认外部完成情况。Maka 禁止投机猜测，从不默认把缺失结果当作失败。工具绑定会声明具体的恢复策略：天然幂等、可查询状态检查、或严格禁止自动重试。当缺乏决定性证据时，运行时停放该操作，等待自动化探针或操作员介入（恢复解析器的取舍详见 docs/architecture/runtime-recovery-resolver-adr.zh-CN.md）。

恢复只做追加，绝不篡改历史

恢复操作本身是 append-only 的：运行时从不编辑先前的function_call事件，也不伪造缺失历史。派发、结果、协调、操作员决策都作为新事实追加到日志尾部；历史事实保持不可变，后续事件记录悬空操作如何收敛。Resume 例程只有在所有挂起操作收敛到 Completed 或 Definitely Not Dispatched 之后，才启动新的执行周期。

重放遵循严格的架构边界：Maka绝不重新执行历史工具实现，也不复活瞬态内存对象、未决 Promise 或已断开的 socket。重放只重建经过验证的因果历史：用户输入、推理轨迹、配对的function_call/function_response事件。

Immutable RuntimeEvent Prefix │ ├── Resolve and converge tool states ├── Strip transient streaming chunks ├── Retain paired Call / Response events ├── Prune uncommitted dangling suffixes └── Verify High-Water mark and Digest │ ▼ Verified Provider Replay Plan │ ▼ Fresh Run / Invocation Instance

恢复的续接实例获得不同的 Run 与 Invocation 标识符，记录其父 run 与 high-water 锚点；原始用户提示不重复，已完成操作不重跑——续接继承的是已验证的历史事实，而非一段命令式的重执行脚本。派发模型请求前，Maka 还会校验环境不变量：工作区路径一致、工具绑定有效、后台任务收敛、无冲突恢复；任一条件无法确认，resume 即中止到 parked 状态（相关契约见 docs/architecture/runtime-resume-phase1-safe-boundary-contract.md）。

Code Mode：程序化编排与折叠调用树

标准工具调用遵循顺序回合模式：模型提议 → 运行时执行 → 模型重新评估。对每一步都需要连续语义推理的工作流，这种模式提供了必要的控制；但对确定性的数据变换，这种往返结构会造成严重的延迟与 Token 开销。

以多包依赖审计为例：Agent 需要遍历几十个目录、检查package.json、提取版本约束、报告差异。在顺序工具调用下，Agent 要重复几十个推理周期：生成读请求、等待文件内容、解析结果、发射下一个调用。原始文件内容灌满上下文窗口，模型往返成倍放大延迟。

Reason → Call → Observe → Reason → Call → Observe → ...

这些工作流中，推理只在初始规划与最终错误分析时必要，中间步骤是确定性控制流。强迫模型模拟循环和字符串解析器，既浪费推理成本，又用中间噪声污染上下文。

程序化编排：从离散调用到可执行程序

Maka 的Code Mode用程序化编排取代离散调用：模型不再发射零碎的工具调用，而是产出一个可执行程序；迭代、并发、分支、解析、聚合都在沙箱解释器内执行，模型只拿到最终的结构化输出。

┌─ Tool A ─┐ Reason → Program ─┼─ Tool B ─┼→ Filter / Join / Reduce → Observe → Reason └─ Tool C ─┘

Maka 的实现基于@ai-sdk/code-mode，集成胶水代码见 packages/runtime/src/code-mode.ts。该模块不持有跨 cell 状态，通过experimental_runCodeMode把沙箱工具调用桥接到宿主工具并等待其排空（drain）。其执行策略DEFAULT_CODE_MODE_EXECUTION_POLICY（同文件 L41-L55）给出了 Maka 实际交付的产品限额，比 SDK 默认值更严格：

沙箱在严格隔离下运行：容器内代码只能访问运行时显式暴露的工具，自定义网络或文件系统逻辑无法绕过运行时权限——脚本是编排层，不是权限升级通道。诊断结果包含parse_error、execution_error、unknown_tool、limit_exceeded、tool_failure五类（CodeModeDiagnosticKind）。

折叠调用树：中间遥测不进入推理内存

Code Mode 不取代标准工具机制，而是把线性调用序列重组为层级调用树：根节点是程序载荷，分支节点是脚本发出的具体工具调用。每个叶子操作仍须通过运行时校验、权限门控与事务边界：

Program / exec ├── Tool Call 1 ├── Tool Call 2 │ └── Tool Result 2 └── Tool Call 3 └── Tool Result 3 │ ▼ Program Result

折叠带来两个主要收益：最小化往返推理步骤，以及把中间遥测挡在上下文窗口之外——沙箱吸收原始操作载荷，只把合并摘要返回外层上下文；完整操作细节保留在审计日志中，不消耗推理内存。

注意使用边界：不可逆副作用、需要人工授权的操作、或后续步骤依赖非结构化语义观测的工作流，仍应使用显式顶层工具调用。Code Mode 面向确定性数据管道，不是隐藏 Agent 决策的工具。

嵌套调用的持久性与崩溃语义

嵌套调用统一经过中央ToolRuntime路由——校验、权限评估、T1/T2 事务一视同仁。嵌套调用获得独立标识符，并与宿主exec事件保持父子链接；它们以modelVisibility: hidden提交到RuntimeEvent Log，模型只看到外层exec边界与其聚合结果——存储保留完整事实历史，推理只看到干净的投影。

崩溃恢复同样覆盖程序化执行：脚本可能执行完三个嵌套操作后在第四个崩溃。若恢复时整体重跑整个脚本，会重复已完成副作用。因此 Maka禁止对未定局的execcell 自动重试：已落定的嵌套操作留在日志中，外层 cell 标记为中断状态，恢复策略交由后续模型评估决定。脚本环境是瞬态的，但每次跨越系统边界的嵌套工具调用都持久化、可审计——这一点在 packages/runtime/src/tests/code-mode.test.ts 与 packages/runtime/src/tests/code-mode-backend.test.ts 中有系统性的用例覆盖。

并行工具执行：把任务并发与资源权威解耦

Agent 可以在 Code Mode 程序内并发发射工具调用，也可以在单个标准 completion 步骤中输出并行调用。并行调用需要清晰的架构定义：模型在一个步骤中输出一批调用时，没有观测到任何中间结果，因此批内调用之间不能存在因果数据依赖；若某个操作依赖另一个调用产出的数据，它必须排在后续推理步骤。

Single Assistant Step ┌── Tool Call A ──→ Result A ──┐ Model ──┼── Tool Call B ──→ Result B ──┼──→ Next Model Step └── Tool Call C ──→ Result C ──┘ Fan-out / Fan-in

从架构上看，批量调用镜像异步 I/O 原语：每个工具调用作为独立可 await 的任务，运行时避免线程阻塞，推进并发任务直至外部文件系统、进程或网络响应；整批落定后聚合结果进入下一步推理。这让独立等待可以重叠——慢速网络查询不会拖延本地文件检查或子代理执行，整体延迟收敛于关键路径而非独立操作之和。

数据依赖缺失 ≠ 资源冲突缺失

模型可能在同一批中发射Read(a)与Edit(a)，或让多个工具同时更新共享会话状态——虽然两者都不消费对方的返回值，但争夺的是同一物理资源。把这类批次直接交给Promise.allSettled()之类的非协调原语，会引入由非确定性执行时序支配的竞态。

Maka 在 PR #4542 中给出的原则是：最大化独立 I/O 并行，同时保证冲突操作具备确定性顺序。把全部并发约束集中到单个 Tool Scheduler 会引入架构瓶颈——期望调度器从工具参数静态推导读写集，是脆弱抽象，在动态宿主环境中必然失败。

异步系统设计提供了清晰的分工：executor 负责调度任务生命周期，resource authority（资源权威）负责治理访问约束。互斥、读写者公平性、容量限制、唤醒信号属于"资源旁边的权威"：异步互斥锁、读写锁、信号量、或持有状态的 actor。

Tool Batch │ Create tasks, allocate result slots, broadcast cancellation ▼ Resource Authority │ Resolve identity, order, enforce exclusivity, check versions, wake ▼ Filesystem / Terminal / Browser / Session / Remote Service

资源权威必须解析真实资源身份：原始路径参数无法揭示物理别名（符号链接可能让不同路径指向同一文件）、多个工具可能操纵同一个浏览器标签页、不同 MCP 调用可能命中同一远程会话。只有直接管理该资源的权威才能仲裁真实争用与提交顺序。批量调度器能减少无谓争用，但不能作为唯一的安全来源——它无法在跨 turn、跨并发子代理、跨外部进程上强制互斥，安全必须在资源权威层收口。Maka 的文件系统侧实现见 packages/runtime/src/filesystem-authority.ts 及契约测试 packages/runtime/src/tests/filesystem-authority-contract.test.ts。

不同资源类型需要量身定制的同步模型：

• 文件系统：规范路径租约（canonical path lease），写者优先或读写公平；
• 终端与浏览器：单状态 actor，强制严格串行操作；
• 外部 API 与 MCP Server：计数信号量，调节并发与请求配额；
• 带版本号的会话状态：基于修订号的 Compare-And-Swap（CAS）乐观并发控制。

这些模式共享异步生命周期，但不必把异构资源塞进单一锁模型。

区分资源争用与容量上限

• 资源争用决定操作能否安全并发执行而不破坏状态；
• 容量上限决定基础设施能支撑多少并发操作。

把上游 API 限流当作全局互斥锁会引入队头阻塞（head-of-line blocking），让慢网络调用卡住无关的磁盘读取。异步运行时应当把阻塞严格限制在真正的物理冲突上，保持独立工作畅通。

当批内调用争用同一资源时，模型生成的数组顺序充当确定性决胜器（tie-breaker）——它确立争用时的优先级，但不代表因果数据流。并行执行涉及四条不同的时间序列：

Model Generation Order ≠ Task Start Order ≠ Task Completion Order ≠ Runtime Event Arrival Order

独立任务乱序开始、乱序完成。原始执行事件按发生顺序提交到日志，通过 Tool Call ID 关联；返回给 provider 的载荷则重新组装为原始提示顺序。历史日志保留物理事实，上下文投影满足模型协议需求。

中止与超时严格遵守结构化并发规则：已排队但被取消的任务不得开始执行；已越过 T1 派发的任务不能简单抛弃——运行时必须等待其收敛并记录最终处置。批量管理器在子任务间维持所有权，确保每个操作在下一次推理步骤开始前完成、中止或达到可验证状态。

沙箱、Serverless 与状态分解

工具调用最终必须在具体计算设施上执行。模型生成行动方案、程序协调控制流，但操作系统进程、内存空间、网络接口都需要物理或虚拟资源。执行目标跨度很广：轻量 JavaScript V8 isolate、带数据科学工具链的 Python 容器环境、以及拥有独立内核与硬件虚拟化的完整 MicroVM。

LLM Generates Intent │ ▼ Agent Runtime │ Select execution environment and capabilities ▼ ┌──────────┬──────────────┬─────────────┐ │ V8 │ Python │ MicroVM │ │ Program │ Data/Scripts │ Full OS Tool│ └──────────┴──────────────┴─────────────┘ │ ▼ Filesystem / Process / Network / Browser

更重的执行环境带有明确权衡：为字符串处理启动完整虚拟机引入无谓延迟，而直接在宿主进程内运行不受信任的 shell 脚本则带来严重安全风险。运行时必须把工具需求动态匹配到轻量、安全隔离的衬底上。

沙箱定义的不仅是安全边界，更是 Agent 执行的资源边界、失败边界与生命周期边界。运行时在沙箱层强制配额：限制 CPU、内存、存储、并发与执行时间；限制网络域名；内存耗尽或进程失败时终止环境，防止系统性不稳定。

状态与计算解耦：沙箱是可丢弃的

传统应用假定长驻本地进程；现代 Agent 环境则把计算衬底视为可丢弃资产：V8 cell 完成即终止、容器空闲超时即回收、MicroVM 在宿主迁移时排空。把持久 Agent 状态绑定到瞬态计算节点会破坏系统可靠性。

Append-only 日志为这种分离提供了基础：会话轨迹、工具调用、结果、权限记录、恢复事件都驻留在持久日志中；大型工件与二进制输出持久化到对象存储；工作区通过 copy-on-write 快照或持久卷挂载。沙箱扮演无状态执行引擎，可在节点间按需重建：

Durable State Ephemeral Compute RuntimeEvent Log ─┐ ┌─ V8 Isolate Artifact Storage ─┼─→ Rehydrate ────┼─ Container Workspace Snapshot┘ └─ MicroVM Preserves "What happened" Executes "Next action"

Agent 负载是突发性的：模型推理时沙箱闲置，编译或批处理时剧烈飙升；有的工具毫秒级完成，有的要阻塞数小时等待外部反馈。现代基础设施必须支持空闲期快速缩容到零，仅在调用时供给专用容量。

Agent Serverless：会话状态彻底脱离计算生命周期

这不同于传统 Function-as-a-Service（FaaS）抽象——标准 Serverless 函数假定短暂、无状态执行；Agent 则维持有状态工作区、派生长后台任务、暂停等待人工评审、数小时后恢复。Agent Serverless 把会话状态与计算生命周期完全解耦：

沙箱终止时，运行时不尝试重建易失进程堆或未决 socket，而是检查持久日志、把工作区快照重水合（rehydrate）进新沙箱，从已验证事实历史恢复执行。

安全架构同样受益：一次性沙箱不持有静态管理凭据或广泛网络访问，每个任务只获得短时、最小权限的能力；凭据存储与策略授权保留在容器外的可信运行时中。即使沙箱被攻破，其授权范围在终止瞬间即失效。

可负担的计算衬底支持舰队级 Agent 部署：单个会话可以为脚本编排供给轻量 V8 isolate、为数据分析供给 Python 容器、为软件编译供给 MicroVM，任务完成后即释放资源。

完全状态分解：S3 上的会话

该架构的自然延伸是完整状态分解：会话状态持久化在成本低廉的对象存储（如 S3 兼容系统）中，计算在按需、无状态的 worker 上执行。会话不再与静态进程或宿主目录关联，而是作为持久对象的集合存在：append-only 事件段、二进制工件、工作区快照、压缩投影、以及指向当前提交边界的 manifest 元数据。交互间隙，会话以极小成本被动驻留在对象存储中。

Cost-Effective Object Storage (S3) Session A ── Events / Artifacts / Workspace Snapshots ─┐ Session B ── Events / Artifacts / Workspace Snapshots ─┼── S3 Session C ── Events / Artifacts / Workspace Snapshots ─┘ │ External Event / User / Schedule │ │ ▼ │ Rehydrate Session Context ◀───┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ V8 Python MicroVM │ │ │ └───────────┼───────────┘ │ Append Facts │ └──────────────→ S3

长驻 Agent 不再需要持久专用服务器。大多数时间它们处于休眠；当消息到达、webhook 触发或调度时间到达时，控制面读取会话 manifest、挂载所需日志前缀与工作区快照、供给合适沙箱；执行落定后新事实同步回存储，计算资源立即释放。

该架构组织为两个协调层：

• Data Plane（数据面）：对象存储管理不可变、高吞吐的事件日志与文件系统快照；
• Control Plane（控制面）：低延迟存储跟踪权威头部指针（head pointers）、资源租约、配额与挂起操作。

这镜像了分解式数据库架构：对象存储提供持久、经济的持久化，计算严格按需供给；上下文组装如同物化视图查询——运行时读取持久状态，应用压缩与结果裁剪，投影出有界上下文供模型推理。

Session on S3 │ ├── Projection ──→ Model Context ──→ LLM │ │ ├── Rehydrate ───→ Sandbox ──────────→ Tool Call │ │ └──────────────── Append New Facts ◀───┘

模型与沙箱都是可互换的计算工具：模型选择随推理复杂度伸缩，沙箱规格匹配工作负载需求，会话从不绑定单一模型供应商或执行衬底。成本效率源于休眠会话消耗零活跃计算；分解存储还支持 spot-instance 执行与瞬时分支——基于 append-only 日志与 copy-on-write 快照，子代理从父历史分叉而不复制存储，只向前写增量记录。

结语：运行时工程决定 Agent 的天花板

工具 schema 持续占据上下文窗口，延迟机制压缩认知表面积但保留全部能力；行动边界把模型提案权与系统授权彻底分离；T1/T2 两阶段提交让外部副作用拥有可审计的崩溃语义；Code Mode 把确定性控制流折叠出推理循环；资源权威在并发安全与容量治理之间划出清晰界线；而不可变日志 + 一次性沙箱 + 对象存储的状态分解，让 Agent 从"长驻进程"进化为"按需重水合的持久事实集合"。

这些设计共同指向 Maka 运行时工程的未来方向：以不可变日志作为权威事实源、以可丢弃沙箱保障安全执行、把资源治理从任务调度中解耦、动态管理 schema 投影以保持模型专注。将语言模型扩展到外部系统，需要的不是更多提示词技巧，而是扎实的运行时工程——这正是本文全部机制存在的理由。进一步深入可阅读 docs/architecture/runtime-host-architecture.md、docs/architecture/runtime-resume-architecture.md 与 docs/architecture/peer-mesh-architecture.md 中的架构推演。

【免费下载链接】makaApache Maka (Incubating) is a high-performance agent workspace that keeps a complete record of everything it did.项目地址: https://gitcode.com/GitHub_Trending/mak/maka