本节汇总智能体编程的工程化实践，聚焦于如何长期、高效、安全地使用智能体进行开发。
10.5.1 上下文管理与对话策略
上下文是智能体的"视野"。管理好上下文，是高效协作的基础。
不需要手动标记每个文件。现代智能体有强大的搜索工具，按需拉取上下文：
❌ 不好的做法：
"请看 @src/api/users.py @src/models/user.py @src/services/user_service.py
@src/repositories/user_repo.py @tests/test_users.py 帮我修改用户验证逻辑"
✅ 好的做法：
"帮我修改用户验证逻辑，登录时需要检查用户是否被禁用"
（让智能体自己搜索相关文件）
虽然智能体擅长搜索，但通过“项目说明文件”（见 附录 12.5）提供项目级的“机器可读说明书”，能减少幻觉与不必要的上下文检索时间。这是智能体编程的“地图”。
提升智能体可读性 (Agent Legibility)
OpenAI 在其工程实践中提出了 "Agent Legibility"（智能体可读性） 的概念。这要求我们不仅为人类写代码，更要为智能体优化代码库。
扁平化结构：避免过深的目录嵌套，让文件路径清晰地反映功能模块。
自描述命名：函数和变量名应尽可能包含语义信息，减少智能体推理上下文的难度。
显性契约：使用类型系统（Type Hints）和接口定义（Interfaces）明确数据结构，作为智能体理解代码逻辑的"锚点"。
[!TIP] 智能体编程黄金法则：如果智能体的实现偏离了轨道，不要试图通过后续对话来"修补"它——这通常会导致代码越来越乱。
正确的做法是：
如果你在 Git 环境中，git reset --hard 或 git stash 回滚更改
记住：一次正确的全新生成，永远优于十次修补。
长对话会导致智能体失去焦点。经过多轮对话和摘要后，上下文积累噪声，智能体可能分心或切换到无关任务。
开始新对话时，引用之前的工作记录，而不是复制粘贴整个对话：
利用 Git 工作树，可让多个智能体同时工作而互不干扰：
创建并行工作环境：
10.5.2 代码审查与人类监督
智能体编程的核心原则：AI 提案，Human 决策。
图 10-19：智能体编程中的人类监督模型
复杂任务的执行应当遵循"计划-执行-检查"的循环：
图 10-20：复杂任务的检查点机制
以下操作应被列入禁止清单，必须通过钩子拦截或人工确认：
图 10-21：智能体操作禁止清单（行为与目标）
可以通过规则文件配置具体的安全护栏。下面是 cursor 的示例：
传统的 AI 编程是线性的（Prompt → Code），而有效的工程实践致力于构建具有记忆的系统。本节将技能系统、钩子系统和复利工程统一为知识沉淀体系。
技能（Skills） 是一种将过程性知识封装为可复用知识包的高级设计模式。
如果说“工具服务”赋予智能体访问外部系统的能力，那么技能则赋予智能体专业领域知识与稳定工作流，而治具负责提供模拟环境与反馈闭环。
技能结构：
图 10-22：技能目录结构思维导图
SKILL.md 编写规范：
技能的加载时机：
钩子（Hooks） 是智能体的生命周期钩子，允许在特定事件发生时自动执行自定义脚本。
生命周期事件：
钩子实现示例：
以下是以 TypeScript 编写的一个典型钩子配置示例。虽然这里使用 TS，但钩子的逻辑（拦截、审计、修改）在任何支持插件机制的智能体工具中都是通用的。
高级模式：长运行智能体循环
通过钩子配合技能，可以创建能自主迭代直到成功的"长运行智能体"：
这种模式将"编写-测试-修复"的循环完全自动化，是智能体编程的终极形态之一。
复利工程的核心在于构建正向循环——智能体的每一次错误都成为系统进化的养料：
图 10-23：复利工程正向循环
[!NOTE] 版本兼容性提示： 智能体工具更新极快，配置文件的文件名和格式可能随版本变化。请务必查阅工具的最新官方文档，但 “将隐性知识显性化” 的复利工程核心思想是永恒的。
知识沉淀形式：
复利效应：
随着时间推移，规则与技能会逐步沉淀，带来更低的返工率、更一致的代码风格与更可控的风险边界。
“基座”（Harness）原指工业生产中用于固定工件、引导刀具的辅助装置。在智能体编程时代，这个概念被重新定义：
基座工程：构建一套包含模拟环境、测试生成器、自动化验证和反馈闭环的“脚手架”，让智能体在其中自主工作并获得准确的反馈。
如果说智能体是“工人”，那么开发者就是“车间设计师”。
一个完整的智能体代码基座（Standard Agent Harness）应包含：
生成器（Generators）：自动生成输入数据、测试用例或初始代码骨架。
验证器（Validators）：不仅检查语法错误（Linter），还检查逻辑正确性（Tests）和业务规则（Policy）。
反馈回路（Feedback Loop）：将验证器的错误信息转化为智能体可读的所谓“修正提示”（Correction Prompt）。
图 10-24：智能体基座工程架构
在传统开发中，如果测试不通过，开发者自己修改代码。而在智能体开发中，测试报错信息是智能体唯一的“眼睛”。
没有基座：智能体写完代码 -> 运行报错 -> 智能体瞎猜 -> 越改越乱。
有基座：智能体写完代码 -> 基座运行测试 -> 返回精确的错误行号与原因 -> 智能体精准修复。
案例：OpenAI 的 HumanEval 基座
OpenAI 在评估 Codex 能力时，不仅仅是看代码能不能运行，而是构建了一个名为 HumanEval 的基座：
在企业落地中，你也应该为你最重要的业务逻辑构建类似的基座，而不是让智能体对着空白编辑器“裸奔”。
10.5.6 刻意练习与进阶路径
为什么有些开发者觉得 AI 没用？因为他们没有进行 刻意练习。
通过反复练习，建立问题处理的"肌肉记忆"：
图 10-25：智能体编程进阶学习路径
智能体编程在企业落地时，最值得关注的往往不是“平均提升多少”，而是能否建立可复制、可治理的工程体系。下面给出一组更稳定的落地要点：
开发周期加速：减少重复劳动，把注意力放在问题定义与验收。
入职时间降低：把关键知识沉淀为文档、规则与技能，降低口口相传的成本。
质量与一致性：用测试、lint、审查与护栏把不确定性锁在可控范围内。
知识传承：隐性知识显性化为规则、技能与可回放的链路。
[!TIP] 案例：OpenAI 的 Harness Engineering
OpenAI 曾披露其内部工程实践：通过构建强大的 Harness（治具），他们将大量繁琐的编码工作自动化。工程师不再手动编写 CRUD 代码，而是专注于维护这个"治具系统"——包括各种 Mock 数据、自动化测试生成器和即时反馈机制。这使得少数工程师能够通过智能体驱动海量的功能开发，且保持极高的代码质量。这正是 Agentic Coding 在企业级落地的终极形态。
下一章: 第十一章：安全、伦理与未来
