最近一段时间我开始实践 AIOps ，即尝试使用 agent 来管理我的个人服务器，帮助我解决个人项目的线上问题。 我目前拥有一台部署在 Digital Ocean 上的 Droplet （也就是传统的 VM ），上面部署有网关服务 Kong 、定时任务平台 Kestra 、6 个 Agent/Workflow ，涉及 4 个 repo 。同时 Kestra 上运行有一个小时级别的定时任务，三个日级别定时任务，五个周级别的定时任务。并且可见日后新增的 agent 或者服务还会继续增加。用业余时间维护这些服务显然已经超过了我能够承受的负荷，因此借助 AI 来辅助我进行维护工作。 人是最大的瓶颈 AIOps 不是一个选项，而是一个结果。因为 AI 带来的生产力提升正在让人成为交付过程中的最大瓶颈——我开始尝试 AIOps 的初衷也是基于此：AI 可以不费吹灰之力将我的想法变为现实，但这只是降低了我的制造成本而非是维护成本，上线之后遇到了太多的线上问题需要解决。如果我依然选择人工去修复每个问题，那从整个交付结果上看效率并没有任何的提升。这里我还需要替 AI 辩解一句，从事后看诸多的线上问题并非是源自生成代码不够健壮，而是来源于意料之外的不确定因素，例如网络抖动、例如第三方后端服务契约的改变。 于是让 AI 应对 AI 就是水到渠成的事，我的第一个 AIOps 版本是：一旦有线上问题发生，某个 debug agent 便会被自动唤起，它不仅能够获取到日志，还可以通过 GitHub MCP Server 获取到源码，从中便可以推断出服务镜像是如何构建以及服务是如何被部署的，它还可以调用 docker CLI 来获取底层的 docker container 运行状态。最后综合以上信息生成一份涵盖 pull request 的解决方案。 听上去很美好是不是，但人作为瓶颈的这个问题并没有被解决。因为 AI 所生成的长篇解决方案、pull request 依然等待着开发者的 review 和批准。某种意义上说，它只是让问题推迟发生了。 当然我们还可以选择将 AI 应对 AI 的策略贯彻到底：用另一个 AI 来评审当前 AI 提出的 pull request——我尝试这么做过，鉴于 debug agent 是基于 Cursor SDK 开发，于是我选择在 GitHub 上集成了 Gemini Code Assistant 来对 Cursor SDK 生成的代码进行评审——但这并没有让情况变得更好，我发现 Gemini 总是能对 Cursor 生成的修改提出“不满”，严重程度均为中度往上的。如果你真的对每一则意见都进行评估，那最后 AIOps 带来的结果是事与愿违：效率不但没有得到提升，还最终你精疲力竭。 到现在你也许已经发现了问题的症结所在：只要人还存在于交付的任意一个环节中，无论是 QA 还是代码评审，端到端的交付效率就无法彻底得到提升。 解决问题的方式很简单：把人移除，让 AI 自身持续改进。我正在尝试这么去做，不过事实上已经有人在付诸实践了，在最近 OpenAI 官方发布了一篇文关于 Harness Engineering 的文章《工程技术：在智能体优先的世界中利用 Codex 》（Harness engineering: leveraging Codex in an agent-first world）中，他们的做法是： 我们会指示 Codex 在本地审核其自身的更改，在本地和云端请求额外的特定智能体审查，对任何人工或智能体给出的反馈做出响应，并循环往复，直到所有智能体审核人员都满意为止……随着时间的推移，我们已将几乎所有的审核工作调整为用智能体对智能体的方式来处理。

如果你有兴趣的话可以深入其背后的深层思想：Ralph Loop。即构建一套自治循环（ autonomous loops ）的系统，人只负责定义目标和约束，让 AI 持续执行任务、测试、修复、提交、部署。 共享工具，独享上下文 在相当长一段时间内有一件事我想不清楚：究竟需要多少个 agent 来解决所有可能发生的线上问题？ 我可以选择按照纵向服务模块来设计，分别给 Kestra 、Kong 、Agents 都准备一个独立的 debug agent 为其服务；还可以选择从横向出发，分别为 host 主机、docker 服务、应用层服务配置 debug agent——所有上面这些想法并不切实际，因为从实际解决问题的角度出发，无论是人还是 AI ，他或它需要的都不仅仅是某个切面的数据，都是每个切面的数据。 我的经验是，信息的收集对于解决问题至关重要。越靠近生产环境，越多的问题可能是由非代码引起的。一旦我们无法找到有效的出错栈信息，那么就需要从基础设施，从跨功能需求上寻找答案，那么如何排除每一种可能呢？信息，贪婪的获取信息至关重要。 本质上 debug 过程遵循的是情报周期（ Intelligence cycle ）：决策者首先确定需求，然后根据需求收集有关的情报，并随之进行整理和过滤，最后对其进行分析并从中找出威胁或者有效信息。决策者还需要根据反馈结果继续决定是否进行下一轮迭代。

例如我发现 Kestra 某几个定时任务的失败是源于 VM 的内存和 CPU 已经满负荷运行，而之所以满负荷运行，部分又是因为多个定时任务的几乎在同一时间运行——在这个例子中，agent 需要在 Kestra 日志，Docker 日志，以及多个源码之间反复横跳才能找到症结所在。 所以即使我需要多个 agent 解决多个纵向领域内的问题（在同一套基础设施环境内），它们的能力也不会有太大差异，完全可以共享一整套的工具（函数）或者 MCP Server 。但解决不同类型问题 agent 需要的上下文却不尽相同。例如对于一个专业解决 Kestra 定时任务有关问题的 agent ，它不仅需要理解 Kestra 自身是如何构建以及部署的，还需要了解每个定时任务背后，那个由 HTTP 触发的后端服务的是如何构建以及部署的；而对于解决 docker 有关问题的 agent 而言，它只需要你给它足够高的 Docker CLI 使用权限就够了。 所以回到本小节开头的那个问题？我们究竟需要多少个 agent ？我的答案是一个就够了，我们可以创建一个拥有各种工具箱的 agent ，然后将上下文信息在调用 agent 时以 prompt 的方式传递给它即可。 你可能会想到其他的一些可能的解决方案，例如 sub agent ，又或者 agent team ，绝大部分框架都已经提供了开箱即用的类似机制。我之所以没有选择一方面是因为简单的架构与代码对我来说颇为重要，二是因为按照我的开发经验看，我对 agent 之间的交互没有信心：agent 的工作过程越是动态，不确定性越高，失败的概率也就越高。 Agent 的部署与落地 最后我们聊聊实现层面的问题。 首先，Agent 必须“寄生”（部署）在应用程序所在的运行环境中，一方面是为了实现我上面所说的，尽可能多的获取应用自身及其所处环境的数据信息（如果程序是运行在如 Vercel 或者 Render 这样的 PaaS 平台上，至少需要保证 agent 能够通过 API 获取到日志信息）；另一方面是为了便于 agent 被及时唤起介入线上问题。整体上看部署在云上的 agent 会比部署在本机的 agent 更有优势。 虽然 agent 部署在远端，但开发者依然需要具备访问它的能力，包括了解它是如何思考的，看到它的解决方案是什么，在必要时与其对话对解决方案进行修改。你可以把这个当作另一种关于 agent 的 observability ，只不过这里指的是将它的工作过程和工作结果可视化，而不是将它 agent 的代码调用过程可视化。 目前并不存在满足上述需求的开箱即用的工具，虽然 Codex 和 Claude Code 在 debug 上是高手，但它们仅仅适用于于本地调试。所以我们需要基于已有的 agent 框架进行二次开发。而根据我以上的描述，agent 框架的需要满足最重要的三点需求：

支持配置 tool 与 MCP Server ，以便与不同的平台和环境集成 框架自身提供 HTTP 接口能够供外界服务服务调用 agent ，这便于 agent 与第三方服务集成 框架提供前端界面供用户与 agent 持续进行对话

虽然并非市面上每一款 agent 框架都具有上述特性，但是能够找到符合以上三点的框架还是不少，比如 Mastra 或者 Ango 。第三点尤其重要，因为如果需要自主实现一个能与 agent 进行交互的单页面应用需要付出不少额外的精力，下图为 agno 的前端应用界面，它可能帮助你可视化的管理 agent 的方方面面。

但最终我既没有选择 Mastra 也没有选择 Agno ，而是选择基于 Cursor SDK 自建，原因来自于模型。 如果选择第三方框架，意味着我需要自行为其提供模型。而出于众所周知的原因，我无法使用官方提供的 sonnet 、opus 或者 GPT-5.4 模型，open router 在我所属的 IP 下也无法提供服务，我还尝试过 Vercel 的 AI Gateway 似乎也无法正常工作。与其继续纠结斗智斗勇不如直接选择可用的服务，例如 Cursor SDK （我可以指定其使用 Composer 2.5 模型）。并且使用独立 AI 模型的另一个弊端是额外的为 API 调用付费，而我相信我的 Cursor 会员能够覆盖这部分的用量。 HTTP 接口怎么办？使用任意 web server 框架对一次 agent 调用进行封装即可。至于前端——我当然可以 vibe coding 一个前端页面，甚至我早就有一个开源项目能够完成这方面工作——考虑我太懒了，以及本质上我们需要的是一个能够可视化 agent 输出以及与其沟通的“场所”而已，有一个更简单的地方可以派上用场：GitHub Issue 。我会确保所有的 agent 的输出都会以一个全新 issue 的方式创建出来，然后利用 comment 这种形式与 agent 进行沟通。 原文发布于此