Loop Engineering 实践: Pi Coding Agent

我在之前写过一些关于AI Agent在开发流程中应用的经验，比如《打造适合自己的 AI Harness 工程：从开发流、E2E 测试到自动排障》。随着对AI Agent的深入实践，我发现人肉打Prompt的日子快要到头了，未来我们更多是设计一个系统，让系统来自动化地与Agent交互。最近我一直在研究 Loop Engineering，并尝试将它落地到我的日常工作中，特别是用 Pi Coding Agent 来实现自动化巡检和代码修复。

1. Loop Engineering 是什么，由哪些环境组成

以前，我们程序员和AI编码Agent的交互模式是这样的：我写一个Prompt，提供上下文，Agent返回结果，我再根据结果写下一个Prompt。Agent就像一个工具，始终在我手里。但现在这种模式正在被 Loop Engineering 所取代。

Loop Engineering 的核心思想是构建一个小型系统，让这个系统自己去发现工作、把工作交给Agent、检查Agent的产出、记录发生的一切，并自主决定下一步行动。我们只需要设计好这个系统一次，之后系统就会自动地与Agent交互。Addy Osmani 将其分解为六个部分：

• Automation (自动化): 触发器，在特定时间、事件或条件发生时启动循环。
• State file (状态文件): 记录循环的进度和历史，让Agent在每次运行时都能从上次中断的地方继续。
• Verifier (验证器): 自动化检查Agent产出的质量，判断工作是否完成或需要返工。
• Skill (技能): 封装项目特定的知识、规则和最佳实践，避免Agent重复学习上下文。
• Connector (连接器): 让Agent能与外部工具（如Git、Jira、Slack、监控系统）交互，使其能在真实环境中执行操作。
• Sub-agent (子Agent): 将复杂任务分解给多个Agent并行处理，通常会有一个“生成者”和一个“检查者”Agent，避免“自说自话”。

用LLM Wiki构建SRE知识库

前段时间，部门leader交给我一个任务：公司SRE平台的工单系统已经累积了7019个人工工单，这些工单里沉淀了大量运维过程中的实际问题和解决经验，leader希望我能用这些数据建立一个SRE领域的专属知识库。

接到任务后，我初步盘算了一下，制定了一个看似顺理成章的计划：

1. 把这7000多个工单全部格式化为Markdown文件，提取工单标题、内容、处理会话以及审批详情。
2. 选型知识库的检索方案，在传统的 RAG（检索增强生成）和最近比较火的 LLM Wiki 之间做个抉择。

但随着项目的推进，我发现事情并没有那么简单。在这个过程中，我对“如何用大模型解决实际工程问题”又有了一些新的体悟，在这里复盘总结一下。

打造适合自己的 AI Harness 工程：从开发流、E2E 测试到自动排障

最近有点忙，主要围绕着打造适合自己的 harness 工程来进行。在之前的《AI工程落地实践》的文章中，我已经基于 superpowers 构建了适合我们团队的 AI 开发工作流：

brainstorming ──→ writing-plans ──→ executing-plans ──┬──→ test-driven-development
                                                      └──→ code-review-expert ──→ learn

但是在这个流程的中间，我发现了一个问题：我需要多次跟 Agent 对话来确认进度，而 Cursor 是以请求次数计费的。这就导致每次开发需求我不仅需要频繁切入确认，还浪费了不少 Cursor 的高级模型请求次数。为了解决这个问题，我在现有的开发流程上增加了一个新的 go 启动 SKILL。

复盘：ClawOps AI Agent

前言

过去的两周，我经历了一次充满激情的开发，也经历了一次彻底的失败。

起因是我准备在内部做一个公共的“运维AI机器人”。我满怀热情地规划了多租户架构、复杂的并发控制、MCP（Model Context Protocol）对接以及各种内部系统的打通。然而，经过两周的爆肝，项目上线没多久就被平台团队勒令下线，而从业务价值来看，老板其实也并不需要这样一个东西。

俗话说，失败是成功之母。虽然项目黄了，但这两周踩过的坑、写过的废代码，都是技术架构演进路上的宝贵经验。我在这里复盘一下整个过程，聊聊我的技术实现、妥协，以及如果让我重新设计，我会怎么做。

AI工程落地实践

前几天在整理项目代码的时候，看着 commit log 里那些由 AI 生成的代码，突然有点感慨。以前写代码是体力和脑力的双重劳动，现在好像变成了单纯的脑力博弈——跟 AI 的博弈。

这篇想絮絮叨叨聊一下从传统的开发模式转变为 Vibe Coding 的过程中，我踩过的坑以及现在摸索出来的一套还算顺手的 SOP。

1. 回顾：前AI时代的手工作坊

在那时候，我接一个大需求，流程基本是雷打不动的：

1. 拆解：把大需求掰碎了，变成一个个小任务。
2. 设计：看老代码，定方案。哪里要改，哪里要加，脑子里或者纸上得有个谱。
3. 搬砖：按计划写代码，写单测。
4. 验证：跑通端对端流程。
5. Code Review：提 PR，等同事挑刺，改代码，合并。

这个过程里，最重要的一步其实往往被忽视，就是复盘。这波开发里学到了什么新模式？引入了什么新坑？怎么避免下次再犯？这种“复利”思维才是工程师成长的关键。