8 篇文章带有标签 “agentic-engineering”

研究编码智能体(Kilo Code)开源项目的最佳实践

研究编码智能体开源项目的最佳实践

基于 Kilo Code 的架构特征和当前编码智能体领域的生产实践 ,以下是系统研究此类项目的 方法论框架

阶段 1:宏观定位(Why & Where)

研究维度 关键问题 Kilo Code 的启示
Fork 溯源 上游是谁?核心差异点?社区分裂原因? Kilo 从 Roo Code 分叉,差异集中在 Cloud 集成和商业化功能
生态位 是「IDE 插件」「CLI 工具」还是「平台」? Kilo 是「IDE 扩展 + CLI + Cloud」的三位一体
许可策略 是否存在 BSL/SSPL 等限制性条款? MIT 许可证,无商业限制
模型绑定 是否硬编码单一提供商? 模型中立是核心卖点,避免供应商锁定

阶段 2:架构解构(How)

建议的代码阅读路径(以 Kilo 为例):

  1. 入口层src/extension/activate.ts(VS Code 生命周期)、src/extension/api.ts(IPC 外部 API)
  2. 核心代理循环 — 查找 Cline/Roo/Kilo 主类,理解 Plan → Act → Verify 的循环
  3. 工具调用层McpHub 如何集成外部工具(文件系统、终端、浏览器)
  4. 上下文管理层 — Memory Bank、Context Mentions、自动索引的实现
  5. 模式系统 — Custom Modes 的解析与切换逻辑
  6. 差异标记 — 搜索 // kilocode_change 快速定位增量代码

Kilo Code:基于智能体工程的自动化软件开发平台

Kilo Code

简介

Kilo Code 是一个开源的一站式智能体工程(Agentic Engineering)平台,旨在通过 AI 智能体(Agents)自动化软件开发全流程。它是目前 GitHub 上非常活跃的项目,核心定位是作为开发者的 AI 辅助引擎,帮助构建、部署和迭代代码。

安装

# npm
npm install -g @kilocode/cli

# Or run directly with npx
npx @kilocode/cli

Kilo CLI

主要功能

Kilo项目核心能力分析

基于项目文档和代码结构分析,Kilo是一个开源的AI编码智能体平台,主要用于加速软件开发过程。它是OpenCode项目的fork版本,增强为全面的agentic工程平台。以下是其核心能力的详细分析:

  1. AI驱动的代码生成与自动化 核心功能:支持从自然语言描述生成代码,例如用户输入"add input validation to the signup form",智能体会自动生成相应的代码片段。 自动化任务:能够自动化重复性编码任务,如重构代码、运行测试、修复错误等。智能体会自我检查工作,确保代码质量。 内联自动完成:提供实时AI驱动的代码补全建议,提升编码效率。

很难说清楚在过去两个月里,人工智能让编程发生了多大的变化:它不是以「往常一样逐步进展」的方式渐进发生的,而是就在去年十二月突然发生的。他指出,由于更高质量模型具备了「长期连贯性和执着性」,编程智能体「在十二月之前基本还不好用,但从那之后基本就能用了」。来源: Simon Willison 的网络日志

Andrej Karpathy

大模型应用开发范式的演变

这四个术语是当前大模型应用开发的核心范式,从指令设计、信息管理、生成式编程到自主智能体构建,层层递进,共同构成了 AI 应用开发的技术栈。

以下是通俗易懂的拆解:

1. Prompt Engineering (提示工程)

这是最基础的技能,重点在于指令的质量。 如果把 AI 比作一个极其博学但有时听不懂人话的实习生,Prompt Engineering 就是学习如何写出完美的“任务说明书”。

  • 核心逻辑:通过调整输入的文字(提示词),引导模型输出更高质量的结果。
  • 常用技巧:给 AI 设定角色(“你是一个资深翻译”)、提供示例(Few-shot)、要求逻辑推演(Chain of Thought)。
  • 比喻:就像是在搜索引擎里输入更精准的关键词,或者给厨师下达非常具体的菜谱要求。

2. Context Engineering (上下文工程)

随着模型处理能力增强,大家发现“怎么说”固然重要,但 “给它看什么资料” 更重要。这就是上下文工程。

  • 核心逻辑:管理和优化输入给模型的信息流。AI 的记忆(上下文窗口)是有限的,你需要精准地挑选出最相关的背景知识喂给它。
  • 典型应用RAG (检索增强生成)。当你问关于公司手册的问题时,系统先去数据库里搜出相关的几段话,塞进对话框里,AI 才能据此回答。
  • 比喻:开卷考试。Prompt 是考题,Context 就是那本允许你带进考场的、划满了重点的参考书。

氛围编程 vs 智能体工程

Andrej Karpathy:氛围编程(vibe coding)

我称之为“氛围编程”(vibe coding)——这是一种全新的编程方式:你完全沉浸在感觉中,拥抱指数级的效率提升,甚至忘掉代码本身的存在。

这之所以成为可能,是因为大语言模型(比如配合 Sonnet 使用的 Cursor Composer)正变得过于强大。而且,我直接通过 SuperWhisper 和 Composer 语音对话,几乎连键盘都不碰。我会提一些极度偷懒的要求,比如“把侧边栏的间距缩减一半”,因为我根本懒得去代码里找位置。我永远点“全部接受”(Accept All),再也不看代码比对(diffs)了。遇到报错信息,我直接原样粘贴回去,一句话都不解释,通常这样就能修好。

代码库的增长速度超出了我以往的理解能力,如果真要搞懂,我得花好长一段时间去通读。有时大模型修不好某个 Bug,我就绕过去,或者要求进行随机改动,直到 Bug 消失。对于那些周末折腾的练手项目来说,这种方式还算凑合,但也确实挺离谱的。

我正在开发一个项目或 Web 应用,但这感觉并不像在编程——我只是观察、动嘴、运行、粘贴,然后它居然大部分时间都能跑通。

Andrej Karpathy:智能体工程(agentic engineering)

很多人转发这条推文,以此纪念“氛围编程”(vibe coding)诞生一周年。简单回顾一下:

安德烈·卡帕西(Andrej Karpathy)发布了一篇微型散文(推文),提到自己买了一台 Mac Mini(“Apple Store 的店员告诉我这东西卖得像热饼一样快,大家都很困惑”),用来折腾 Claws

我对直接运行 OpenClaw 确实还有点怀疑……但我非常喜欢这个概念。我认为,就像 LLM 智能体(LLM agents)是建立在 LLM 之上的新层级一样,Claws 现已成为建立在 LLM 智能体之上的全新层级。它将编排、调度、上下文、工具调用以及某种持久性提升到了一个新的水平。 环顾四周,既然这种高层级的理念已经很明确,许多更小型的 Claws 已经开始涌现。例如,粗略浏览一下,NanoClaw 看起来非常有趣,它的核心引擎只有大约 4000 行代码(它既能装进我的脑子里,也能装进 AI 智能体的“脑子”里,因此感觉可控、可审计且灵活),并且默认在容器中运行所有内容。…… 总之,还有很多其他的例子——比如 nanobot、zeroclaw、ironclaw、picoclaw(这些前缀真让人发笑)。…… 目前我还不能 100% 确定我最终的配置会是什么样子,但 Claws 绝对是 AI 技术栈中一个令人兴奋的全新层级。

安德烈对新鲜术语有着极强的敏锐度(比如之前他提出的 “氛围编码 / vibe coding” 和 “智能体工程 / agentic engineeri

Andrej Karpathy

直接和它对话——智能体工程的实用指南

Peter Steinberger (OpenClaw 的创造者) 分享了核心主张 “拒绝套路,直接对话”。他认为当前的 AI 智能体(尤其是 GPT-5-Codex)已足够强大,无需过度依赖 RAG、复杂的子智能体或繁琐的规格文档等“炒作”手段。

最近我在这里变得安静了许多,因为我正埋头于最新的项目。Agent 智能体工程(Agentic engineering)已经变得如此强大,以至于现在它几乎包揽了我 100% 的代码编写。然而,我看到仍有许多人在解决问题时,还在搞那些华而不实的复杂套路,而不是专注于把活干完(Getting sh*t done)。

这篇文章的灵感部分来自昨晚在伦敦参加的 Claude Code Anonymous 交流会,部分原因是从我上次更新工作流以来已经过了“AI 领域的一年”(实际才几个月,但变化巨大)。是时候同步一下进度了。

所有的基本理念仍然适用,所以我不会再提上下文管理等简单的事情。你可以阅读我的 《AI 开发最佳工作流》 作为入门。

背景与技术栈

我独立工作,当前项目是一个约 30 万行代码(LOC)的 TypeScript React 应用,包含 Chrome 扩展、CLI、基于 Tauri 的客户端以及基于 Expo 的移动端。我使用 Vercel 托管,一个 PR(拉取请求)大约在 2 分钟内就能交付新版本网页进行测试。

以推理速度交付:为什么我不再阅读代码,而是看着它飞速流转

Peter Steinberger (OpenClaw 的创造者) 分享了他在使用 AI 智能体构建软件方面的最新经验,特别是关于如何以推理速度交付代码,以及他对模型(如 GPT 5.2 和 Opus)的看法。

自五月以来的变化

“氛围编程”(Vibe Coding)在今年取得的进步令人不可思议。大约在五月份时,我对某些提示词(prompts)能直接生成可运行的代码感到惊讶,而现在,这已经成了我的预期。我现在的代码交付速度快到不真实。从那时起,我消耗了大量的Token。是时候更新一下心得录了。

这些智能体(Agents)的工作方式很有趣。几周前有人争论说,为了感受糟糕的架构,人必须亲手写代码,使用智能体会导致脱节——我完全不同意这种观点。当你花足够多的时间与智能体合作,你就会准确地知道某件事应该花多少时间。当 codex 回来时如果未能一次性解决问题,我立刻就会产生怀疑。

我能创建的软件数量,现在主要 受限于推理时间硬核思考。坦率地说——大多数软件并不需要硬核思考。大多数应用只是把数据从一个表单搬运到另一个表单,也许存进某个地方,然后以某种形式展示给用户。最简单的形式是文本,所以默认情况下,无论我想构建什么,它都始于 CLI(命令行界面)。智能体可以直接调用它(CLI)并验证输出——从而闭环

模型转变

真正解锁像工厂一样构建软件能力的,是 GPT 5。