• 作者: 作者
  • 时间:
  • 分类: 文章

最近在折腾一个很有意思的项目：完全自主的 AI 编程 Agent。

现在市面上 Copilot、Cursor 确实好用，但它们本质上还是个“增强版补全工具”，时刻需要你盯着屏幕敲击。我一直想搞个真·无人值守的“开发替身”——你丢给它一个 Issue，喝杯咖啡回来，代码已经写好、测完甚至提交 PR 了。

借着 WorkBuddy 提供的便利，我试着把这个想法落地了。最终成果非常性感：核心逻辑只有 180 行代码，挂载了 7 个工具，并且拥有 100 万 Token 的超长上下文记忆。

Telegraph 在 CNB 用 WorkBuddy 从零手搓一个自主 AI 编程 Agent：180 行核心循环 + 7 个工具 + 1… #WorkBuddy开发者分享季 项目背景 CN

项目成果概览：核心逻辑仅 180 行代码，挂载 7 个工具，支持 100 万 Token 上下文。

今天就来拆解一下这个“手搓 Agent”的技术实现思路，看完你也会觉得，构建属于自己的 Agent 其实离我们并不远。

一、为什么想自己造个 Agent？

背景是 CNB 平台上原本就有一个内置的 NPC 助手，但它太“乖”了。功能受限，只能做简单的问答，没法真正介入代码仓库，更别提自主操作了。对于想在平台上搞点自动化开发流的同学来说，这就好比给了个只有显示屏没有键盘的电脑。

我的需求很明确：

  1. 全自主接管：在 Issue 或 PR 里 @ 一下，它能直接读取仓库代码，理解业务逻辑。
  2. 不仅是读，还要做：不仅能分析代码，还要能运行终端命令、修改文件、创建新的代码文件。
  3. 具备项目管理能力：甚至能派出“分身”（子 Agent）并行处理不同的文件，最后汇总结果，全程不需要我干预。

最终，这个 Agent 以 Docker 镜像的形式发布，部署运行一条龙，完全符合现代开发者的交付习惯。

AI Agent 核心架构图

Agent 的核心循环：感知、决策与行动。

二、架构设计：极简的核心循环

很多人听到“Agent”觉得高大上，其实剥去外壳，核心就是一个感知-决策-行动的循环。

这个项目的核心逻辑被我压缩到了 180 行 Python 代码 里。它的运行逻辑清晰到令人发指：

  1. 接收指令：监听平台事件（比如有人提了个 Issue）。
  2. 提取上下文：去把相关的代码文件、历史对话、Issue 内容全部抓取过来，塞给大模型。
  3. 思维链推理：让大模型分析“现在要干嘛”，“缺什么信息”，“该动哪个文件”。
  4. 工具调用：如果是读文件，就用文件读取工具；如果是改代码，就用写入工具；如果需要测试，就调用 Shell。
  5. 迭代与反馈：根据工具执行的结果（比如报错信息），再次进入循环，直到任务完成。

这种设计最大的好处是可调试性极强。出了问题，你只需要看这 180 行的状态流转，一眼就能定位是模型理解错了，还是工具挂了。

三、“瑞士军刀”：7 个核心工具

Agent 的智能不完全取决于模型有多强，更取决于它手里有什么工具。我给这个 Agent 配置了 7 个关键“器官”：

  1. read_file：基础的文件阅读能力，能精准定位代码行。
  2. write_file：能够创建或覆盖文件，支持代码生成。
  3. list_directory：这就是“眼睛”，用来浏览项目结构，找到目标文件在哪。
  4. run_command：赋予它操作系统的能力，比如 npm install、pytest、git commit 都靠它。
  5. search_code：在庞大的项目中快速检索关键字或函数，不用漫无目的地瞎逛。
  6. patch_file：这个很关键，用于局部修改代码。很多时候 Agent 生成重写整个文件的代码会出错，精细化的 Patch 能提高成功率。
  7. git_operation：直接操作 Git 仓库，创建分支、提交变更。

有了这套组合拳，Agent 就不再是一个只会空谈的“嘴炮”，而是一个能实际撸起袖子干活的“实习生”。

四、100 万上下文：为什么对编程至关重要？

聊架构时，不得不提一个显眼的数字：100 万 Token 上下文。

在很多对话式 AI 里，上下文限制是最大的痛点。写个稍微大点的项目，早几轮的对话就被“遗忘了”，导致 Agent 重复犯错或者逻辑断裂。

但对于编程 Agent 来说，长上下文是“刚需”而非“锦上添花”：

  • 全局视野：它能一次性读完整个项目的核心依赖、配置文件和关键模块，不会因为没读过 utils.py 就在那瞎写调用。
  • 长链路记忆：在处理复杂 Bug 时，它能记住十分钟前的尝试方案，避免在同一个坑里跌倒两次。
  • 少样本学习：可以在 Prompt 里塞进大量的优质代码示例，让生成的代码风格强制符合项目规范。

实测下来，有了百万级上下文，Agent 在处理多文件引用时的“幻觉”大幅减少，生成的代码第一次跑通的概率明显提升。

五、WorkBuddy 平台带来的便利

在这个项目里，WorkBuddy 其实扮演了“基础设施”的角色。它不仅提供了 Docker 运行环境，更重要的是打通了 LLM 与工具之间的桥梁。

相比于自己从头搭建一套 WebSocket 服务去对接各种大模型 API，直接用现成的平台能让你把精力全放在“设计 Prompt”和“编写工具逻辑”上。这也是为什么能在这么短时间内完成开发的原因——不要重复造轮子。

六、遇到的坑与解决思路

当然，过程也没那么顺畅。这里分享几个实战中遇到的问题和解决思路，给想动手的同学提个醒：

  • “死循环”风险：Agent 有时候会把错误的代码改来改去，陷入死循环。
    • 解法：在核心循环里加了一个最大步数限制（Max Iterations），比如超过 5 次操作还没解决，就强制停止并向人类求助。
  • 命令执行权限：在容器里跑 rm -rf 这种命令太危险了。
    • 解法：通过沙箱机制限制，或者在执行高危命令前增加一道“确认”步骤（虽然这牺牲了一点全自主性，但为了安全值得）。
  • 成本控制：长上下文是真烧钱。
    • 解法：实现了一个简易的 RAG（检索增强生成），只在必要时把全量代码丢给模型，平时只存摘要。

写在最后

其实，构建一个 AI Agent 并没有想象中那么遥不可及。这次“手搓”经历让我明白，核心不在于你用了多牛的模型，而在于你如何设计那个“循环”以及如何定义它的“工具集”。

随着 100 万上下文逐渐普及，未来的编程方式可能会发生剧变。我们不再只写代码，而是在写“如何指挥 AI 去写代码”的流程。

如果你也对这种全自主开发感兴趣，不妨去试着跑一下这个 Docker 镜像，或者基于这 7 个工具扩展出属于你自己的超级 Agent。

标签: none

评论已关闭