Stacklok 的 Craig McLuckie 认为，编程代理不应继续绑定在开发者的设备及其交互式工作流上，并介绍开源项目 Mecatl，将其作为一种分布式架构范例，把代理循环与客户端、执行环境、工具和支持服务分离。
编程代理的价值已不再局限于回答问题的聊天界面。其实用性与其拥有强大的工具、共享的代码仓库和文件系统、子代理，以及能够保存系统从先前工作中学到内容的技能密切相关。根据 Stacklok 的 Craig McLuckie 的说法，下一步是将这些能力从开发者的计算机转移到长期运行的服务和接口上，供那些甚至可能根本不会打开终端的人使用。
问题在于，大多数现有的代理运行框架都是围绕桌面模型设计的：单个用户、单台设备、本地文件系统，以及一个同时汇集用户界面、代理循环、隔离环境、凭据存储、工具托管和会话数据库的交互式进程。这种模型适合个人开发者，但当企业需要运行数百个会话、对工具实施精细策略、在节点故障后恢复会话，或在不同设备之间切换时，它就不再那么合适。
将代理循环与系统其他部分分离
McLuckie 建议构建他所称的“云原生运行带”，从一开始就将其作为分布式应用，而不是简单地把桌面框架放进容器。容器或许能改变进程的运行位置，但无法拆解其组件之间的相互依赖。在 Stacklok，开源框架 Mecatl 正是为此目的提供的。
在 Mecatl 中，核心负责代理循环，包括推理、工具调用分发、权限、钩子和事件发布。其他元素则通过明确的接口与其连接：
- 终端客户端和 API，包括名为 mecatui 的 TUI、gRPC 和 HTTP/SSE 接口，以及 TypeScript SDK。
- 执行环境、工作区和命令运行器，代理在其中执行任务。
- 工具体系，包括内置工具、通过流式 HTTP 提供的 MCP 服务、技能以及应用专属集成。
- 支持服务，用于管理模型提供商、会话状态、事件日志、身份和协调。
实际会发生什么变化？
这种分离使代理循环成为可像其他服务一样进行版本发布、部署和监控的组件。它可以在终端中运行，也可以作为服务运行，或运行在 Kubernetes 上，而无需替换代理循环本身。在 mecak8s 指南中，可以在运行期间替换工作节点，同时在发布新版本时保留持久会话。
会话状态和事件日志会根据单写入者协调模型存储在持久化存储中。如果工作节点发生故障，备用工作节点可以从最近保存的轮次边界继续执行。但这并不等同于分布式事务：故障发生时正在运行的操作不会被恢复，最近一次成功保存之后完成的工作也可能丢失。因此，项目将这一能力描述为轮次级连续性，而不是完整的分布式事务保证。
明确的目录还能够限制获准使用的工具、技能和集成，并对权限、审计和执行环境设置边界。由于客户端不拥有文件系统、凭据或会话状态，同一个代理循环可以为终端、远程服务、嵌入式应用或 Kubernetes 部署提供服务，甚至还能将 Web 界面、Slack 集成和协作编辑器连接到同一个会话。
尚未解决的问题
消息来源确认，Mecatl 仍处于早期阶段，“云原生运行带”更多是一种架构方向，而不是完整规范。其中一个主要问题是确定调用外部系统的主体身份：是用户、代理、会话，还是多层级的子代理？该项目提出了自己的 SPIFFE 信任域，并在 JWT 中编码完整的委托链，使接收系统能够依据身份链作出决策。
该项目还在研究超越 MCP 的工具路径，使 PDF 分析器之类的工具能够直接在文件系统上工作，而不是将所有输入和输出都通过模型的上下文窗口传递。与此同时，“上下文证明”的概念也随之出现，即像对待软件供应链中的任何制品一样，对打包后的上下文进行发布、签名、溯源、分发并纳入策略管理。
编辑解读：这一方案的重要性不在于推出一个新的界面，而在于将代理重新定义为可管理的服务，而不是一个长期运行的个人进程。不过，消息来源明确区分了 Mecatl 当前能够运行的部分与仍处于设计阶段的部分；当前的连续性机制也无法防止正在进行的工作丢失，并且身份模型或工具之间直接传输数据的方式尚未确定。因此，在将这一模型视为适用于所有本地代理框架的现成替代方案之前，需要根据部署环境、权限边界和数据保障进行实际评估。