智能体工程：构建可靠编码智能体的实用指南

HN Enterprise Copilot Adoption 2026-08-28T05:56:17.334065

智能体工程（Agentic engineering），就是把编码智能体放进一个完整的工程体系里：上下文、任务范围、验证方式、证据和人工审查，全都清清楚楚、有据可查。模型可以负责规划并写出代码，但它说了不算——自己写的东西对不对，不能由它自己来判定。

当然，这只是我下的定义。这个说法出现没多久，目

前还指代好几种不同的东西，我也不打算假装它有什么 ISO 标准。

真正有用的区分标准，不在于“代码有没有被大语言模型（LLM）碰过”，而在于信任放在哪里。如果你的流程是“写提示词、扫一眼结果、上线、祈祷别出事”，那叫 vibe coding（随性编码）。如果流程里有可审查的需求、受限的操作权限、自动化的检查、留痕的证据，还有一个对最终结果负责的人，那才叫“用智能体做工程”。

这套流程，是我一点一点搭进 my-pi（一个基于 Pi 构建的编码智能体工作环境）里的。这篇指南把这些零散的部分串在了一起：约束框架（harness）、项目规则、调研、上下文检索、语言服务器协议（LSP）诊断、评测、遥测、密钥处理，以及多智能体协作。每一节都附上了更深入的实现链接——凡是我有的话。

什么是智能体工程？

智能体工程是这样一种软件工程形态：智能体承担开发循环里相当一部分工作，而工程师负责设计这些工作得以发生的环境。

编码智能体可以查看代码仓库、搜索文档、修改文件、运行命令，并针对结果继续行动。比起自动补全，它有用得多，但错误也因此有了“容身之处”。一个错误的假设，可能变成一次代码改动；一个被遗漏的约束，可能变成一个新引入的依赖；一份信心十足的总结，可能在真正有用的测试压根没跑的情况下，就宣称“验证已通过”。

工程的重心也随之往上提了一层。你仍然关心代码，但还要关心：

Andrej Karpathy 在 2026 年初让「智能体工程」这个词流行起来。当时他意识到，用智能体编程这件事，已经超出了他早先提出的「氛围编程」所能描述的范围。这个名字挺实用，但背后的工作并不神秘——无非是把规格说明、工具、权限、测试、可观测性和代码评审，用在一个跑得飞快、确实好用、但结果带有随机性的「工人」身上。

智能体工程与氛围编程的区别

氛围编程以结果为导向，刻意保持随意。你描述想要的东西，让模型生成代码，跑一下看看效果，不满意就再改提示词，直到感觉对了为止。这种方法做原型、写一次性工具、探索某个想法时，确实很好用。

问题在于，有人假装这套信任模式对生产环境软件同样够用。

生产环境的代码库里有太多快速演示掩盖不了的东西：权限、数据迁移、故障恢复、审计日志、无障碍支持、性能、既有代码规范，还有用户不按顺序乱点一气的奇怪操作。「我刚才点了一下能跑」，并不能证明这些系统仍然正常工作。

智能体工程保留了速度，但更换了验收标准。智能体依然可以负责大部分代码书写，但一项任务只有当仓库里的检查通过、任务自身的成功条件也满足时，才算真正完成。

两者之间仍有一条模糊的界线。Simon Willison 写过，随着模型能力提升、无人监督的成功结果越来越多，我们也会越来越愿意信任它们，智能体工程和氛围编程正在相互靠近。我也有同感。危险不在于使用更多的自主性，而在于反复的成功悄悄拆掉了那些能提醒你「下一次运行出了问题」的护栏。

可靠的智能体工程工作流需要什么？

不存在放之四海皆准的技术栈。改文档和做数据库迁移，需要的工具完全不同。下面这些部分，是我在反复实践中认为确实能留下来的。

先找回「事实来源」

一个全新的智能体会话，只知道自己收到的提示词，以及框架塞进来的上下文。它不会自动知道某个架构选择当初为什么这么定、上周哪些地方失败了、或者用户的哪次修正改变了任务方向。

我一开始会先找回证据：

  1. 检查仓库及其本地指令

  2. 找到当前实现和对应的测试

  3. 如果任务有历史，调取相关的早期会话记录

  4. 从一手资料出发，研究外部 API 和文档

  5. 在基于假设动手之前，先明确列出这些假设

目标不是“上下文越多越好”。一份庞大的指令文件反而会挤掉它本该辅助完成的任务。目标是把相关的上下文放进去，让智能体需要时能随时再取出来。

这也是为什么我做了 pirecall 来管理会话历史，又做了一个 SQLite 上下文伴生文件（context sidecar）来装大型工具输出。两者都能把一大片文字变成可检索的东西。智能体拿到的是筛选过的证据，而不是我产生的每一条消息和每一行日志。

让项目知识“可执行”

AGENTS.md 文件适合记录稳定的项目规则，但它不是一道力场护盾。

如果某条规则重要到一旦被打破就会伤害代码库，我会尽量把它表达成软件形态：类型、lint 规则、边界检查、测试、hook 或 CI 命令。自然语言只是告诉智能体“什么样子算好”，真正能拦住“看起来合理的走捷径”变成下一个局部惯例的，是确定性的检查。

这一点我在《如何阻止 LLM 在生产代码库中跑偏》里写过。做法很简单：

同一个修正如果反复出现，那就越来越应该把它改成一条检查。

把高风险任务约束在对话之外

提示词适合表达意图，但不是守住信任边界的好地方。

对于有实质风险的工作，我会使用一个外部任务框架（task harness）。它会把允许的路径、禁止的操作、校验命令、任务状态和收集到的证据，统统记录在执行器的工作上下文之外。智能体可以在新事实出现时调整实施方案，但不能悄悄扩大自己的权限，也不能删掉它觉得碍事的检查。

这个区分很重要。静态计划可能出错，可编辑的外部策略又算不上真正的策略。我的防护框架把固定的信任边界与内部执行脚手架分开——内层脚手架可以修改，但要附上理由并留下审计记录。

完整的设计与结果见 coding-agent harnesses with my-pi。简单来说，一个防护框架应当回答：

并非每个任务都需要这套配置。为一个拼写修复搭建微型软件工厂，是仪式感，而非严谨。

把验证权交还给智能体

智能体无法修复自己看不到的故障。

我把开发者日常用的那类反馈都暴露给它：类型错误、单元测试与集成测试、浏览器检查、lint 输出、构建结果、语言服务器诊断。我更倾向在工作过程中提供聚焦的反馈，收尾前再跑一遍仓库更全面的检查。

把 LSP 加进 my-pi 带来的增益比我预想更大。智能体可以只请求已修改文件的诊断，而不必每次编辑后都跑整个项目的检查；它还能查找定义和引用，不用靠猜符号从哪儿来。

关键在于：完成检查不是“智能体说看起来没问题”，而是一个独立的命令或可观察的结果。对用户旅程来说，这可以是加载页面并真实走一遍；对迁移来说，这可以是检查最终的 schema 和数据。一个只验证了模拟回退的绿测，并不能证明功能真的可用。

记录轨迹，评估结果

如果每次会话都沉进对话记录里，编码智能体就很难持续改进。

我加了本地遥测来记录会话、模型和工具的使用。我也保存可检索的会话历史，并在改动提示词、工具或检索策略时做针对性评估。这让我能问出更好的问题：智能体用上新工具了吗？它找对来源了吗？改动是否减少了无用输出？护栏有没有拦住它本该拦截的那个故障？

实现细节见《Adding Telemetry to my-pi》和《Hardening Redaction with Evals and Telemetry》这两篇。

评估不只是检查智能体写出的最后一句话。结果才重要。Anthropic 举过一个很好的例子：订机票的智能体。对话记录里可能写着“航班已预订”，但真正的结果是要看预订是否真的存在。编程工作也一样。要评价仓库的最终状态和用户的完整旅程，而不是看摘要说得有多自信。

把密钥和权限当作系统级问题

拥有 shell、文件系统和网络访问权限的编码智能体，其爆炸半径比一个聊天框大得多。提示注入也不仅限于用户输入的内容。它可以藏在网页、Issue、依赖的 README 或工具响应里。

我采用窄权限工具、明确的审批边界，以及尽量减少密钥暴露的命令执行方式。我构建了 nopeekso，这样智能体在运行一个依赖凭据的子进程时，不必先把整个 .env 文件打印到对话里。它并不能让任意子进程输出变得安全，但能消除一条常见且不必要的暴露路径。

更广泛的规则很简单：只给智能体完成任务所需的最小权限，把破坏性或公开的操作放在人工审批边界之后。

只有在工作真正并行时才使用更多智能体

多智能体工作法在任务可以独立推进时很有用：一个智能体研究 API，另一个绘制现有实现的地图，或者不同智能体在隔离的工作树里干活，由一位负责人审查结果。

但当五个智能体都需要同一批文件、背景和决策时，这种做法的价值就大打折扣。那不过是制造了一个协调问题，然后把它叫作“规模化”。

我在团队模式下工作时，重点放在所有权、可靠的交接和明确的审查上。负责人仍然需要理解合并后的结果。把任务委托出去，不等于把责任转移给一团蜂群状的云。

在实际使用中是什么样子？

我没有一个干净的基准测试能证明我的工作流能让所有编码任务都更快。不同的项目、模型和任务都让这种说法很难站得住脚。

但我有实践中的证据。

2026年6月28日到7月25日之间，Agent 在104轮会话、10个真实项目工作区里创建了173个有记录的任务测试床（task harness）。其中144个至少一次进入完成状态，155个留下了验证或审查证据，强制机制在69轮会话中拦截了133次动作。

这些数字并不能证明每项完成改动都是好的。但它至少说明：这套系统在演示之外真的被用起来了，Agent 会经常产出可供审查的证据，可执行的边界也确实拦下了真实行为。

同时也暴露了一些短板：

最后一点很关键。Agent 工程（agentic engineering）不是“加更多测试床”，而是针对眼前的风险和复杂度，设计刚刚好的系统。

哪些做法行不通？

不管用哪个模型，总有几种模式反复翻车。

更用力地提示

反复说“别跑偏”“小心点”“确保测试通过”，也许能管用一轮，但形成不了持久的约束。规则要是重要，就给它写个测试，或者把它移到执行者的权限之外。

把所有东西都塞进上下文

上下文越多并不等于越好。超大的指令文件、所有可用的 MCP 工具、整场会话的完整记录，反而让真正相关的信息更难找。应该用渐进式披露（progressive disclosure）和可检索的资料源。

让 Agent 自己审查自己

自我审查有用，但它不是独立证据。要跑检查、看 diff，风险高的改动还得走独立的审查路径。如果规划、实现、自我审查三个阶段共享同一份上下文，同样的错误假设很可能一路存活下来。

把说不清的部分自动化

如果人类自己都说不清想要什么结果，把任务交给更多 Agent，通常只会得到更多输出，而不是更清晰。先做调研、讨论、写个小原型，往往才是正确的下一步。

如何开始智能体工程？

你不需要照搬我的工具。从一个反复出现的真实失败入手。

  1. 写下成功条件。 描述可观察到的结果，而不只是你预期会改动的文件。
  2. 加上最便宜的确定性检查。 用现成的测试、类型检查、lint 规则、浏览器走查或边界脚本。
  3. 把检查暴露给智能体。 在工作过程中给它有针对性的反馈，并在完成前要求它跑完整套检查。
  4. 保持指令简短。 把稳定的项目指导放在仓库里，并链接到更深入、可检索的文档。
  5. 限制访问。 把路径、命令、凭据和外部副作用都限制在任务所需的范围内。
  6. 记录证据。 保留评审所需的命令、结果、决策和剩余风险。
  7. 失败后评审系统。 问问是哪种能力或控制缺失了，而不是只告诉下一个模型“再努力点”。

从那里起步。只有当反复失败或任务风险说明确有必要时，再加更多机制。目标不是最大化自动化，而是用最小的工作流让结果值得信任。

核心要义

最好的编码模型会变，而好用的工作流应该能在这种变化中存活。

就我实践而言，智能体工程不是把软件交付交给自主智能体然后撒手不管，而是让更多工作可以被委派出去，因为周围的系统能够恢复上下文、执行边界约束、返回有用的反馈，并向人类展示实际发生了什么。

模型是快速、概率性的工人；仓库、工具、检查和评审流程才是那个工程系统。

我信任的是后者。

深入阅读

参考资料

这里还有一个「反应排行榜」，你也可以去看看。

本文暂无分析数据。

相关文章……

用 my-pi 搭建编码智能体框架

我是如何与 LLM 协作的

构建 my-pi：用 Pi 打造属于自己的 Claude Code 替代方案

用评测与遥测加固 my-pi 的脱敏功能

看来你已经翻到本页底部了！

可惜！

订阅邮件通讯

想持续关注我正在做的最新进展吗？

和其他开发者一起，订阅邮件通讯吧。

查看原文