1. Manus 的带来的思考

当前大家可能对 Manus 的通用智能的概念已经不陌生了。但大家有没有思考过，Manus 与其他智能体的差异到底在哪里？是 Manus 中的智能体的沙箱机制吗？是的。但又不全是。

Manus 披露他们使用 CodeAct 机制来使得智能体的执行更为高效，这确实是个非常关键的点。我们在《基于LLM的数据仓库》的那篇文章中也做过尝试，让大模型根据 python 的报错反馈修正，可以将35%的成功率提升到80%。

基于LLM的数据仓库的自反馈查询引擎实验

当看到 CodeAct 的时候，我也在反思一个问题，为什么当年做了这个 LLM 数仓的实验后，没有朝 CodeAct 的方向去尝试。问题出在哪里？

我仔细想了一下，问题出在反馈的交互(Interface)选择上，普通的 Python 并不是一个良好交互反馈环境，比如运行代码报错可能缺少一些 pip 包，但是这个安装命令又要跑到 Linux 命令行中。

Manus 的沙箱机制让我们发现，设计智能体其实可以站在巨人的肩膀上，操作系统(Operating System)和文件系统(File System)是比较好的一个自反馈的交互系统：

• 操作系统沉淀了计算机领域几十年系统设计，进程状态码、标准输出、错误输出、报错堆栈等一应俱全。
  
• 文件系统提供了一个树形存储结构，方便各种应用场景的读写与分析。
  

所以这个思考就解答了我的一个问题：在 Manus 中很多操作明显可以封装成标准的指令，为什么还要费劲巴拉地使用 linux 命令来做？比如截图中的这种。

Manus中在沙箱中操作文件目录

因为 manus 让智能体的整个推理上下文保持在操作系统中，无论什么问题，都让智能体使用操作系统的办法来解决。这是个重点，后面我们还会再用到。

Manus 优秀的基于 OS 的智能体设计在我心里留下一颗种子，直到 Anthropic 发布 Claude Integrations，又给我了另外一颗种子。确切地说，可能是我对 Integration 这个词过于敏感了，因为我当前本职工作是围绕基于 GitOps 的 CICD 展开的，CICD 是 CI/CD 的缩写，全称为“持续集成/持续交付”（Continuous Integration/Continuous Delivery）。

所以 Claude Integrations 看似好像进入到了我的范畴？于是我开始思考 Claude 的 Integrations 和持续集成中的 Continuous Integration 之间的关联？

• 集成本质上都是将功能聚合到一个操作平面，使得操作更加高效。
  
• CICD 中 Integration 在大多数场景下是指用代码开发了一个新功能之后，需要进入已有的程序或平台之中，有点像一个 Push 的操作。
  
• Claude 的 Integration 是在其 MCP 协议之上的更进一步的服务集成，毕竟 MCP 中的 tools 可能相对会碎片化一些，服务集成会比 tool 更高效。在这里有点像一个 Pull 的操作。

所以，我们可以看到无论是 Claude 的模式还是 CICD 的模式，都有一个具体的目标，Claude 的目标是其平台，而 CICD 是其交付的平台。就这点而言，CICD 的集成是一种更通用更广义的集成。当前 CICD 交付的一般都是传统的平台或系统，如果让 CICD 交付的是个智能体，那么是不是 CICD 可能和 Claude 的 Integration 就是一回事情了？怀着这个大胆的想法，我们稍微做一些设计上的尝试。

2. 基于 GitOps 持续集成的智能体设计

在 GitOps 中的领域，workflow 是个比较成熟的方案，其重点就是通过一个 git branch 产生 CI pipeline，去进行交付。在这个 CI pipeline 中，一般会根据 git branch 中的内容构建一些二进制文件，然后推送到云平台做部署。因为构建不同编程语言的 bin，操作系统可能会有所差异，构建行为一般是启动一个容器或虚拟机来进行。这个特性是不是和 Manus 的沙箱设计有点像了？是的。我们继续。

常见GitOps中的workflow示意

我们参考这个图的拓扑结构做一些修改。参考 Manus 各种披露出来的信息，里面包含了很多智能体，我们先放最典型的计划智能体(Planner)和执行智能体(Executor)。

那么，如何让整个智能体运行起来呢？我们可以来理一下整个流程：

• git 本身就是一个文件系统的存储结构，我们可以将用户问题放在 git 仓库中，同时用户如果还有一些其他 pdf 之类的材料也可以放进去。
  
• 在计划智能体的 pipeline 中，他创建虚拟机，checkout 出这个 git branch 之后，就能够看到用户的问题，然后计划智能体就可以进行规划，写一份类似 todo.md 放进 branch 中。
  
• 然后根据 todo.md，我们就可以让执行智能体(Executor)去干活，每个执行整体在虚拟机中执行的结果继续存到 git branch 中。
  
• 最后，这样一来，就等于普通用户只需要创建一个分支，将问题放进去，等几分钟之后，在这个分支中，用户就能查到他提问的答案了。
  

看起来好像似乎可行？我们尝试来进行一下落地。

3. GitOps 智能体落地实战

首先，我们先来介绍代码平台的持续集成能力。我们可以使用 YAML 来配置一个流程(workflow)，当前 Git 仓库中发生一些事件（例如 git push 等）会自动触发。每个流程(workflow)中可以包含一个或多个可以按顺序或并行运行的作业(job)。每个作业(job)都将在其自己的虚拟机或容器内运行，并且具有一个或多个步骤(step)。

然后，我们将一个 git 仓库设定为一个智能体，那么这个智能体的记忆就是他的 git 仓库。一开始我们将各种数据全放在一个分支下，发现整体结构有点乱，于是我们借鉴操作系统内核的设计，分出了这样两个分支：

• brain 分支：类似操作系统的内核，里面存放 agent 和内置 tool，存放能进行稳定推理的可执行程序。
  
• memory 分支：类似操作系统的用户数据，可以存放任意结构的数据，但需要有几个特定目录用来存放推理时的数据。
  

这两个分支的目录结构完全不同，没有共同父 commit，无法进行合并。

一开始，我们的设计是 memory 分支在每次推理完之后，合并回来，这样我们发现主的 memory 分支很快就充斥着各种不太有用的数据，而且也非常容易将 memory 分支打爆，于是我们重新设计了一个合入的逻辑，每次推理完之后，并不合入 memory 主分支，直接丢弃掉，直接让智能体总结有用的经验合并回主分支即可。这样也可以确保每次总结的经验均是文本，且长度可控。

我们来看一下实际运行的效果。比如当前有这样一个问题：

这个任务我们期望的效果就是智能体能够将这个 helm 包下载下来，然后分析这个变量的引用路径，告诉我应该如何正确使用这个变量。

3.1 步骤1. 构建任务分支

我们将当前问题构造到 chat 目录中，形成一个用户提问。

3.2 步骤2. 计划智能体（Planner）分解任务列表

计划智能体根据用户问题分解出树形的 plan.json，类似 Manus 中的 todo.md。同时给出第一个任务的内容

3.3 步骤3. 执行智能体 (Executor) 执行任务<-->计划智能体 (Planner) 安排下一个任务

我们通过 branch 中的 network 可以清晰地看到每个执行智能提干了哪些活。

• 执行智能体(Executor)使用 CoT 不断地在 CI 工作流的容器中，调用工具来分析问题，解决问题
  
• 计划智能体(Planner)获取每次执行智能体的任务结果，安排步骤2中任务列表的下一个任务。
  

至此，通过这样的三步，我们就可以构造出一个类似 Manus 的智能体，我们可以来对比一下这个问题 Manus 中的执行效果:

左侧为 GitOps 智能体的执行返回，右侧为 Manus 的执行返回

左侧为 GitOps 智能体的任务列表，右侧为 Manus 的任务列表

通过对比我们也可以看出，GitOps 智能体可以做到与 Manus 类似的效果。不过借助代码平台已有的持续集成能力，智能体部分的代码仅仅为500行左右。那么，也就是说基于 GitOps 这样一个架构，我们可以非常低成本地开发各种智能体。

4. GitOps 智能体的优势

4.1 记忆和检索增强(RAG)

git 仓库中的 memory 分支承载智能体的记忆，智能体自身的经验信息存储可以不断地被优化：每一次成功的任务执行或失败的尝试，都有可能为智能体带来新的学习素材，并通过这个机制转化为可复用的经验。同时也可以在外部人为地快速在 memory 分支中加入已有各种经验，使智能体快速具备某个专业领域的能力。

4.2 推理过程可观测

在落地大模型相关的工程的时候，可观测常常是个比较关注的问题，因为我们需要关注这个过程中提示词的变化，看看是否有什么特定词语导致某个非预期的推理等问题。Git + CICD 天然地帮我们解决了这个问题，通过观察 git commit 可以快速看到整个推理过程，如果需要更明细地调用过程，可以直接看 CICD 任务的执行日志。

Planner构造任务列表时的日志

4.3 低成本、低依赖、serverless

整个 GitOps 智能体没有引入一个新的平台依赖，不需要部署一个新服务，均使用现成的代码平台和持续集成能力即可。这使得 GitOps 智能体方案可以快速地被部署到任何环境中。

4.4 跨环境适配、横向扩展

当我们看到 MCP 方案的时候，深深地被 MCP Server 的设计所吸引。如果在笔记本上启动一个 MCP Server，Claude 居然就能操控我本地各种文件，实在是惊艳。而 Git 化的智能体方案也同样具备这样的能力。为了满足复杂的构建需求，持续集成任务是支持机器自托管的。在需要托管的机器上安装一个客户端之后，持续集成任务就直接会被发送到那台机器上。

再延伸一下，原本搭建一个含沙箱的推理工程，可能需要搭建一个 k8s 集群，现在可以把所有的机器用自托管的方式挂上去，这样就免去了 k8s 集群的维护成本？（当然，持续集成平台任务本身通常也是基于 k8s 来做 pod 调度的）。

智能体自进化

进化大概分为几块：

• memory 分支结构进化：智能体可以反复分析所有他做过的任务，调整 memory 分支数据排布，使得其能够做出更好的表现。
  
• brain 分支能力进化：当前我们只是简单地实现了 Planner 和 Executor 两个 agent，实际上 Manus 还有很多 agent，我们可以使其进化出更多的 agent 来提供服务。
  
• 进化路线选择：这有点类似达尔文进化论，不是所有的进化路线都是对的，有些物种进化到死胡同之后会灭亡，有些不正确的 prompt 可能会使得智能体越跑越歪也需要被干掉。所以我们可以借助低成本的优势，clone 出多个 git 仓库，让他们自行进化，最终取能力最强的那个 git 仓库。
  

5. 总结

Manus 给我们提供了一个很好的智能体的样本，通过 GitOps 我们可以低成本实现一个与其能力近似的智能体。

所有 GitOps 智能体相关的代码存放在下面的路径，欢迎有兴趣的同学切磋探讨。

agitops 推理脚手架

推理样例

6. 参考材料

• Executable Code Actions Elicit Better LLM Agents
• AI大模型时代下运维开发探索第二篇：基于LLM的数据仓库
• What Is GitOps and Why Should We Care?
• Manus 背后的重要 Infra，E2B 如何给 AI Agents 配备“专属电脑”？
• 了解 GitHub Actions
  

来源  |  阿里智能运维公众号

作者  |  钟炯恩