热门关键字:  听力密码  听力密码  新概念美语  单词密码  巧用听写练听力

统驭工程

中国水利水电出版社
    【作 者】姜汉龙 陈百顺 著 【I S B N 】978-7-5226-4493-6 【责任编辑】王开云 【适用读者群】科技 【出版时间】2026-05-20 【开 本】16开 【装帧信息】平装(光膜) 【版 次】第1版第1次印刷 【页 数】276 【千字数】396 【印 张】17.25 【定 价】79 【丛 书】人工智能前沿技术应用丛书 【备注信息】
图书详情

    本书是中文世界第一部系统阐述“统驭工程”的著作。“Harness”取义于驭马术—不是限制力量,而是把强大但不可预测的力量导向有用的方向。作者将 OpenAI、Anthropic、Karpathy 等近年提出的工程实践与真实生产事故的教训整合为一套完整方法论,并提炼出贯穿全书的统驭工程七原则:明确边界、最小暴露、可观测性、防御深度、快速降级、成本意识、持续验证。

    全书15 章内容覆盖上下文工程、工具调用、结构化输出、Agent 编排、多 Agent 可靠性、安全工程、人机协作设计、RAG 系统工程、Agent 记忆工程、成本优化、Agent 评估与 LLMOps,配以可运行的代码示例与生产案例,帮助读者把 AI 应用真正从 Demo 推到生产。

    在 AI 能力爆发式增长的时代,掌握“驾驭”AI 的工程方法,比追逐每一次模型更新更具持久价值。

    为什么是“统驭”

    “Harness”这个词,在英语中有一段值得玩味的语义演变。

    它最古老的含义来自驭马术—一套完整的缰绳、胸带、鞍具,用来驾驭一匹强壮但不可预测的动物。驭具不是为了限制马的力量,而是为了将力量导向有用的方向。没有驭具的马是一匹野马;有了驭具的马,可以拉犁、拉车、奔跑千里。

    在软件工程中,“Harness”经历了四个语义阶段,见表0-1。

    表0-1 Harness工程演进的四个语义阶段

    阶段 时间 含义 代表

    第一阶段 2020年前 Test Harness = 自动化测试执行框架 JUnit、pytest

    第二阶段 2021—2024年 Evaluation Harness = 大语言模型(Large Language Model,LLM)评估标准框架 EleutherAI lm-Evaluation-Harness

    第三阶段 2024—2025年 Agent Harness = 智能体(Agent)运行时基础设施 Anthropic Effective Harnesses

    第四阶段 2025—2026年 统驭工程(Harness Engineering)= 工程方法论 OpenAI官方命名

    2026年2月,OpenAI发布了“Harness Engineering: Leveraging Codex in an Agent-First World”。文中披露:3名工程师在5个月内,用AI Agent构建了一个包含约100万行代码的产品—没有一行是手写的。他们对此的定义不是“自动编程”,而是“Harness Engineering”:

    “Harness engineering refers to a shift in the engineer’s role: away from manually writing code and toward designing the environment, specifying intent clearly, and building the feedback loops that allow agents to autonomously build and maintain software.”

    几乎同时,安德烈·卡帕西(Andrej Karpathy)宣告了“Vibe Coding(随性编程)”时代的终结,提出了“Agentic Engineering”—统驭Agent的工程学。卡西·科泽科夫(Cassie Kozyrkov)直接以“Harness Engineering: How to Supervise Code You Can’t Read”为标题撰文。阿迪·奥斯曼尼(Addy Osmani)出版了Beyond Vibe Coding(O’Reilly, 2025)。2025年12月,Linux Foundation成立了智能体AI基金会(Agentic AI Foundation,AAIF),Anthropic将模型上下文协议(Model Context Protocol,MCP)捐赠为公共基础设施。

    一个新的工程学科正在成形。

    中文世界需要一个精准的对应词。我们选择了“统驭”—“统”代表系统性的全局治理,“驭”回到了Harness最原始的驭马隐喻。统驭不是控制(Control),不是编排(Orchestrate),不是对齐(Align)。它是一种更完整的工程实践:将强大但不可预测的AI能力,通过精心设计的基础设施,导向可靠、安全、可观测的生产输出。

    这就是本书的主题。

    这本书写给谁

    1.使用AI编程工具的软件开发者

    无论你是用Claude Code(Anthropic命令行编码智能体)写后端、用Cursor(AI编码IDE)搭前端,还是用Codex(OpenAI编码智能体)做自动化—只要你在用AI写代码并需要让这些代码可靠地运行在生产环境中,这本书就适合你。

    你的工作场景可能涉及两类:使用AI辅助编程[用Claude Code、Cursor、GitHub Copilot(GitHub AI编码助手)等工具编写和维护代码],或者开发基于大模型的应用[用LLM API构建检索增强生成(Retrieval-Augmented Generation,RAG)系统、Agent工作流、智能客服等产品]。无论哪种场景,你都会发现Demo很容易做,但生产化很难—幻觉(Hallucination)率在规模下不可接受、成本超出预算、安全审查无法通过、模型升级导致回归。

    这本书就是为了解决从Demo到生产这段距离的困境问题。本书聚焦于应用层的工程实践—如何设计上下文、如何调用工具、如何编排(Orchestration)Agent、如何保障安全与可靠性、如何控制成本和评估质量。模型本身的微调(Fine-tuning)训练、推理(Inference)基础设施部署、企业组织变革等话题不在本书范围之内。

    阅读前提:本书假设读者具备Python编程能力、基础的API开发经验、基本的命令行和Git操作能力,以及对LLM API(如OpenAI或Anthropic)的初步使用经验。不需要机器学习或深度学习背景—第2章会为应用开发者建立必要的模型直觉。

    2.技术管理者和AI产品经理

    你需要理解 AI 系统的工程约束—不是模型的能力边界,而是将模型能力转化为可靠商业价值的系统工程约束。

    对技术管理者而言:本书可帮助你建立对生产AI系统的工程直觉,理解Demo到生产之间为何存在巨大鸿沟、团队投入应该聚焦在哪些环节(上下文工程、评估、安全、成本)、技术债务如何在AI项目中以新的形式累积。你将能更准确地评估技术方案、规划路线图、与工程团队对齐目标。

    对 AI 产品经理而言:本书可帮助你理解模型能力的实际代价与边界—为什么“智能体能否可靠完成任务”取决于上下文设计而非模型选型、为什么人机协作(HITL)是产品形态而非附加项、如何用七原则评估特性的可落地性。你将能更准确地把模型能力翻译为可交付的产品体验。

    阅读提示:参见下文“如何阅读本书”中的路径四。

    如何阅读本书

    全书分为6个部分,共15章,每个部分可以独立阅读,但存在依赖关系:

    【第一部分:开发基础】Ch1-2

    范式变革 → 语言模型

    ├—→【第二部分:核心工程】Ch3-7

    │ 上下文工程 → 工具调用工程 → 结构化输出工程 → Agent 编排与状态管理 →

    │ 多 Agent与工程化实践

    ├—→【第三部分:安全与人机协作】Ch8-9

    │ 安全工程 → 人机协作工程

    └—→【第四部分:数据与记忆】Ch10-11

    RAG系统工程 → Agent 记忆工程

    └—→【第五部分:生产实践】Ch12-14

    成本优化工程 → Agent 评估工程 → LLMOps工程

    └—→【第六部分:未来展望】Ch15

    边界在哪里

    推荐的四种阅读路径:

    路径一:全栈工程师(顺序阅读)

    Ch1 → Ch2 → Ch3 →…→ Ch15。适合希望系统性掌握全部技术栈的读者。

    路径二:快速上手(最小可行路径)

    Ch1→ Ch4→ Ch6→ Ch8→ Ch13。这五章内容能构建一个可投入生产的最小Agent系统。

    路径三:AI辅助编程实践者

    Ch1→ Ch3→ Ch7→ Ch12→ Ch15。这五章内容可使读者理解如何高效使用AI编程工具。

    路径四:技术管理者与 AI 产品经理(概念优先路径)

    Ch1→ Ch2→ Ch9→ Ch12→Ch15。这五章内容为你提供与工程团队对话的共同语言,无须执行代码即可掌握关键工程约束。

    七原则速览

    贯穿全书的统驭工程七原则(表0-2)是本书的原创理论框架。每一章都标注了涉及的主要原则(⊙)和次要原则(◎),章末提供对应的设计检查清单。

    表0-2 统驭工程七原则

    原则 核心含义 违反后果

    明确边界 清晰界定AI自主权与人类控制权的边界 过度授权(Open Web Application Security Project,OWASP(开放Web应用安全项目)LLM06)

    最小暴露 AI只能访问完成当前任务所必需的最小资源集 数据泄露、横向移动

    可观测性 所有AI决策和行动必须可追踪、可审计、可重放 无法调试、合规风险

    防御深度 不依赖单一安全层,构建多层纵深防御 单点突破全线崩溃

    快速降级 系统部分失败时,保证核心功能可用,而非全面崩溃 单组件故障全系统瘫痪

    成本意识 每个技术决策都必须考虑总拥有成本(Total Cost of Ownership,TCO),AI不是免费的 失控的API账单

    持续验证 不信任单次测试,持续监控线上表现,防止质量漂移 模型更新导致无声退化

    统驭工程七原则不是理想化的设计准则,而是从生产事故中提炼出的工程教训。Air Canada聊天机器人承诺虚假退款政策(缺乏明确边界)、AWS Lambda递归调用产生$47000账单(缺乏成本意识)、Bing Sydney在长对话中角色漂移(缺乏持续验证)—每一条原则的背后都有一个真实的教训。

    关于数据时效性

    AI领域的迭代速度意味着本书中引用的具体数据(模型排名、API定价、Stars数、市场份额等)将不可避免地随时间变化。本书引用数据的时效性截止日期为2026年3月。

    然而,本书的核心价值不在于具体数据,而在于工程原则和架构模式。正如马丁·克莱普曼(Martin Kleppmann)2017年出版了Designing Data-Intensive Applications,书中引用的具体工具已经更新了多个版本,但阐述的分布式系统原则至今仍是行业标准—我们相信统驭工程七原则和架构模式将具有类似的持久价值。

    具体的工具版本、API变更和最新数据,请参考本书配套的GitHub仓库,我们将持续更新。

    关于代码示例

    本书中的代码示例遵循以下约定:

    语言:Python 3.11+,少量YAML/JSON配置

    完整示例:每章不超过3个完整可运行的代码示例,标注运行环境要求

    示意代码:用于说明概念的简化代码,标注“# 示意代码”

    配套仓库:完整代码、配置文件和环境说明在GitHub仓库

    所有代码示例优先使用开源工具和开放API标准。当涉及特定供应商(如Anthropic Claude、OpenAI GPT)时,同时提供通用接口[如多LLM(LiteLLM统一网关)]的替代方案。

    本书所有配套资源,如GitHub库、示例完整代码等请登录www.wsbookshow.com下载。

    致谢

    本书的写作得益于全球AI工程社区的开放精神。

    感谢OpenAI的郭查理(Charlie Guo)在The Emerging Harness Engineering Playbook中对工程实践的系统总结;感谢Anthropic的可解释性团队在归因图和Sleeper Agents研究中对AI安全的前沿探索;感谢安德烈·卡帕西从“Vibe Coding”到“Agentic Engineering”的思想演进为本书提供了完整的时代叙事弧;感谢西蒙·威利森(Simon Willison)、阿迪·奥斯曼尼、卡西·科泽科夫(Cassie Kozyrkov)对Harness工程师职业身份的精彩论述。

    感谢LangChain(LLM应用开发框架)、LlamaIndex(RAG密集型Agent框架)、vLLM(高性能LLM推理引擎)、SGLang(RadixAttention推理引擎)、LiteLLM、Langfuse(LLM可观测性与Prompt管理)、MLflow(ML生命周期管理平台)等开源项目的贡献者们—本书中的每一个架构模式,都建立在你们的工作之上。

    感谢于鑫、王昕等多位活跃在技术社群的资深架构师,他们分享了大量Claude Code Harness实践经验,为本书提供了宝贵的一线工程洞察。

    感谢每一位在GitHub Issues中报告Bug、在Discord中分享经验、在arXiv上发表论文的工程师和研究者。AI工程的知识是集体智慧的结晶,本书只是试图将其中一部分组织为可教授的体系。

    最后,感谢读者。在AI能力爆发式增长的时代,你选择了学习如何负责任地使用这些能力。这是一个值得尊敬的选择。

    作 者

    2026年3月于北京

    第一部分 开发基础
    第1章 范式变革:从Vibe Coding到统驭
        工程 2
    1.1 AI辅助编程的四次变革 3
    1.1.1 第零次变革:代码补全
       (Intellisense时代) 3
    1.1.2 第一次变革:AI补全 3
    1.1.3 第二次变革:随性编程 4
    1.1.4 第三次变革:统驭编程 5
    1.1.5 四次变革对比 7
    1.2 统驭层长什么样:以Claude Code
       为例 8
    1.2.1 全貌:给AI搭一个工位 8
    1.2.2 CLAUDE.md:上下文工程的
       起点 9
    1.2.3 Rules:按需加载的模块化约束 10
    1.2.4 Skill:可复用的工作流模板 11
    1.2.5 MCP:工具调用的标准接口 11
    1.2.6 Hook:确定性的安全与自动化 12
    1.2.7 Memory:跨会话的经验积累 13
    1.2.8 其他工具的对应结构 14
    1.3 为什么Prompt Engineering不够 15
    1.3.1 DORA悖论:采用率90%,组织
       改善为零 15
    1.3.2 METR的反直觉:老手用AI
       反而更慢 15
    1.3.3 安全债:45%的AI代码含漏洞 15
    1.3.4 成本失控:从广告价格到
       真实TCO 16
    1.3.5 提示工程的三重天花板 16
    1.4 Harness的控制论隐喻:驭马
       与驭AI 16
    1.4.1 什么是Harness 16
    1.4.2 Harness的架构化定义 17
    1.4.3 Harness的六大职责 17
    1.4.4 “没有Harness的AI是孤立的
       智能” 17
    1.5 Agent成熟度模型 18
    1.6 统驭工程七原则 19
    1.6.1 为什么需要统驭工程七原则 20
    1.6.2 统驭工程七原则全景 20
    1.6.3 统驭工程七原则之间的关系 22
    1.6.4 统驭工程七原则映射矩阵 23
    1.7 全书路线图 23
    1.8 实战:配置你的第一个AI工位 24
    1.8.1 五分钟CLAUDE.md模板 24
    1.8.2 从零编写一个Code Review Skill 25
    1.8.3 三个必配Hook 26
    1.9 本章小结 27
    第2章 语言模型:应用开发者需要
        知道的 29
    2.1 Transformer:注意力的直觉理解 29
    2.1.1 从序列到序列:自回归生成 29
    2.1.2 注意力机制:核心公式与工程
       含义 30
    2.1.3 位置编码:序列中的“地址” 30
    2.2 Token与上下文窗口:资源约束
       视角 31
    2.2.1 什么是Token 31
    2.2.2 上下文窗口:你最宝贵的资源 31
    2.2.3 Token经济学 32
    2.3 温度、Top-P与采样策略 32
    2.3.1 从Logits到Token:采样的本质 32
    2.3.2 Temperature:控制“创造力”
       与“确定性” 32
    2.3.3 Top-P核采样与Top-K 33
    2.3.4 采样策略对Harness设计的影响 33
    2.4 从预训练到对齐:工程师视角 34
    2.4.1 三阶段流水线 34
    2.4.2 监督微调(SFT):教模型
       “说人话” 34
    2.4.3 为什么Harness不能仅依赖模型
       对齐 34
    2.5 推理模型:推理时计算扩展
       新范式 34
    2.5.1 从“训练更多”到“思考更久” 34
    2.5.2 DeepSeek-R1:强化学习驱动的
       推理革命 35
    2.5.3 Extended Thinking:推理预算的
       工程化暴露 35
    2.5.4 推理预算的Harness设计模式 36
    2.6 模型能力边界:幻觉、事实锚定
       (Grounding)与校准 36
    2.6.1 幻觉不是Bug,是特性 37
    2.6.2 Grounding:用外部知识锚定
       模型 37
    2.6.3 校准与置信度 37
    2.7 模型选型:Harness工程师的决策
       框架 37
    2.7.1 选型决策矩阵 37
    2.7.2 级联路由 38
    2.7.3 开源与闭源:治理问题 38
    2.8 实战:模型选型与参数调优实验 38
    2.8.1 模型选型决策脚本 38
    2.8.2 Extended Thinking对比实验 39
    2.8.3 采样温度对比 40
    2.9 本章小结 41
    第二部分 核心工程
    第3章 上下文工程:信息架构学 44
    3.1 上下文工程与提示工程 44
    3.1.1 从措辞到架构 45
    3.1.2 LangChain四大策略框架 46
    3.1.3 七大Agent上下文工程模式 47
    3.2 Lost in the Middle现象与应对 48
    3.2.1 认知科学视角 48
    3.2.2 工程影响 48
    3.2.3 最优排列策略 48
    3.2.4 缓解策略清单 49
    3.3 三层记忆架构 50
    3.3.1 为什么需要分层记忆 50
    3.3.2 三层记忆架构详解 50
    3.3.3 生产中的分层记忆策略 51
    3.4 上下文预算管理实现 51
    3.4.1 为什么需要预算管理 51
    3.4.2 预算分配模型 51
    3.4.3 预算管理的关键设计决策 55
    3.5 键值缓存与前缀缓存 55
    3.5.1 KV Cache的基本原理 55
    3.5.2 Prefix Caching:跨请求的KV
       复用 56
    3.5.3 API层面的提示缓存 56
    3.5.4 推理引擎层面的KV Cache工程 56
    3.5.5 KV Cache对上下文工程的影响 57
    3.6 提示压缩:LLMLingua与Token级
       优化 57
    3.6.1 为什么需要压缩 57
    3.6.2 LLMLingua:Token级压缩 57
    3.6.3 压缩、摘要与截断 58
    3.7 实战:Agent循环中的上下文
       管理 59
    3.7.1 Agent上下文的生命周期 59
    3.7.2 上下文压缩触发策略 59
    3.7.3 过度工程化Harness 60
    3.8 长上下文与RAG:架构决策框架 60
    3.8.1 一个150倍的成本差异 61
    3.8.2 决策框架 61
    3.8.3 混合架构 62
    3.9 实战:构建上下文预算管理器 63
    3.9.1 核心实现 63
    3.9.2 与Claude API集成示例 65
    3.10 本章小结 65
    第4章 工具调用工程:契约与防错 67
    4.1 Function Calling的工作原理 67
    4.1.1 协议解剖:一次完整的工具调用
       往返 68
    4.1.2 OpenAI与Anthropic:关键格式
       差异 70
    4.1.3 两类工具架构 70
    4.2 工具描述即合同:Poka-yoke
       七原则 70
    4.2.1 为什么工具描述如此重要 70
    4.2.2 防错设计七原则 71
    4.3 工具爆炸与Tool RAG 73
    4.3.1 工具数量的性能断崖 73
    4.3.2 Tool RAG:动态工具检索 73
    4.3.3 Agent基础设施三大协议:MCP、
       A2A与AGENTS.md 74
    4.4 并行工具调用与依赖管理 75
    4.4.1 并行调用:一次响应多个工具 75
    4.4.2 竞态条件防范 77
    4.4.3 禁用并行调用 78
    4.5 工具错误处理与自我修正 78
    4.5.1 错误返回机制 78
    4.5.2 自动修正循环 79
    4.5.3 失败率的复合衰减 80
    4.6 工具权限分级 80
    4.6.1 三级权限模型 80
    4.6.2 Claude Code的权限实践 81
    4.6.3 OpenAI Codex CLI的三级审批
       模式 82
    4.7 BFCL:工具调用能力基准 82
    4.7.1 伯克利函数调用排行榜 82
    4.7.2 Gorilla LLM:RAT训练范式 83
    4.7.3 CodeAct:代码即工具调用 83
    4.8 生产级工具调用Harness 83
    4.8.1 完整的工具执行框架 84
    4.8.2 可观测性集成 85
    4.9 实战:设计防错工具定义 85
    4.10 本章小结 89
    第5章 结构化输出工程 90
    5.1 三大平台Structured Output对比 90
    5.1.1 OpenAI:首个原生Structured
       Output 90
    5.1.2 Anthropic:三种方式可组合 91
    5.1.3 Gemini:额外的约束能力 92
    5.1.4 三平台选型决策 93
    5.2 Pydantic + Instructor:生产实践 93
    5.2.1 为什么是Instructor 93
    5.2.2 自动重试机制:Self-Healing输出
       循环 94
    5.2.3 流式Pydantic对象 94
    5.2.4 统一多模型接口 94
    5.3 受约束解码原理 95
    5.3.1 理论基础:文本生成即状态机
       转移 95
    5.3.2 主流开源库对比 95
    5.3.3 CRANE:约束与推理的平衡 95
    5.4 复杂嵌套结构设计 96
    5.4.1 Agent执行计划建模 96
    5.4.2 判别联合类型 96
    5.4.3 递归结构 96
    5.5 重试机制与验证错误反馈 97
    5.5.1 三级验证策略 97
    5.5.2 验证错误反馈循环 98
    5.5.3 降级策略 98
    5.6 结构化输出的Harness集成 99
    5.6.1 Tool Use与output_config的选择 99
    5.6.2 生产级结构化输出管线 99
    5.7 实战:Pydantic + Instructor结构化
       输出三模式 100
    5.7.1 基础提取模式:一次调用返回
       结构化数据 100
    5.7.2 自动重试模式:验证错误触发
       Self-Healing 100
    5.7.3 流式输出模式:流式返回Partial
       Pydantic对象 101
    5.8 本章小结 102
    第6章 Agent编排与状态管理 104
    6.1 五大编排模式 104
    6.1.1 模式一:提示链 105
    6.1.2 模式二:路由 106
    6.1.3 模式三:并行化 107
    6.1.4 模式四:编排者-工作者 107
    6.1.5 模式五:评估者-优化者 108
    6.1.6 模式选型决策流程 109
    6.2 状态机设计:约束Agent行为 109
    6.2.1 为什么需要状态机 109
    6.2.2 八态Agent有限状态机 110
    6.2.3 安全状态转换引擎 111
    6.2.4 LangGraph状态机集成 112
    6.3 规划机制演进:从线性到树状 114
    6.3.1 演进路线 114
    6.3.2 ReAct:Agent编排的基石 114
    6.3.3 ToT:分支探索 115
    6.3.4 LATS:统一推理、行动与规划 116
    6.3.5 规划算法选型决策框架 117
    6.4 实战:五大编排模式最小实现 117
    6.5 本章小结 120
    第7章 多Agent与工程化实践 122
    7.1 多Agent编排:从实验到行业标准 122
    7.1.1 多Agent并行:工具生态全景 122
    7.1.2 四种拓扑结构 123
    7.1.3 工具过载与专家路由 123
    7.1.4 A2A协议:Agent互操作标准 124
    7.1.5 多Agent框架概览(截至2026年
       3月) 125
    7.2 Spec-Driven Development:从Vibe
       Coding到工程化 125
    7.2.1 SDD的三个成熟度层级 126
    7.2.2 SDD与TDD/BDD:互补而非
       替代 126
    7.2.3 核心工具生态 126
    7.2.4 SWE-bench发现:统驭层工程价值
       的最强实证 126
    7.3 长程任务编排 127
    7.3.1 后台Agent实践 127
    7.3.2 检查点与恢复 127
    7.3.3 任务分解前沿:MAKER框架 128
    7.4 可靠性工程模式 128
    7.4.1 熔断器(Circuit Breaker,断路器
       模式) 128
    7.4.2 超时级联 129
    7.4.3 重试与指数退避 129
    7.5 实战:规约驱动开发全流程 130
    7.5.1 Spec文件模板 130
    7.5.2 Plan文件模板 130
    7.5.3 实现指令 131
    7.5.4 验证脚本 131
    7.6 本章小结 132
    第三部分 安全与人机协作
    第8章 安全工程:攻防一体 134
    8.1 Prompt Injection五层分类学 134
    8.1.1 五层攻击分类 135
    8.1.2 各层攻击详解 135
    8.1.3 HouYi:86%的应用存在漏洞 137
    8.2 五层防御体系 137
    8.2.1 纵深防御的哲学 138
    8.2.2 五层架构 138
    8.3 OWASP LLM Top 10 2025全景 141
    8.3.1 完整威胁列表 142
    8.3.2 LLM07的特殊性 142
    8.4 安全设计实战:完整工作流 143
    8.5 实战:为你的Agent加装安全
       防线 144
    8.6 本章小结 146
    第9章 人机协作工程 148
    9.1 人类监督光谱:HITL / HOTL /
       HOOTL 149
    9.2 风险分级:不是所有操作都需要
       审批 150
    9.2.1 四级审批框架 150
    9.2.2 触发条件设计 151
    9.2.3 Partnership on AI三维风险分类 152
    9.3 LangGraph interrupt():HITL核心
       原语 153
    9.3.1 工作机制 153
    9.3.2 两类中断方式 153
    9.3.3 必须掌握的规则 154
    9.3.4 生产级实现 154
    9.3.5 Checkpoint后端选型 155
    9.4 超时与降级:当审批者不在时 156
    9.4.1 超时策略 156
    9.4.2 级联超时与升级 157
    9.4.3 审批疲劳的工程对策 158
    9.5 HITL与权限系统的集成 158
    9.5.1 从风险分级到权限矩阵 158
    9.5.2 审计日志 158
    9.6 从HITL到HOTL:信任递进
       模式 159
    9.6.1 实证数据:信任的量化增长 159
    9.6.2 产品案例:Claude Code的渐进式
       自主设计 159
    9.6.3 HOTL工程要求 159
    9.6.4 HOTL的三个失败点 160
    9.7 实战:风险分级与审批流程实现 160
    9.7.1 风险分级矩阵 160
    9.7.2 LangGraph interrupt()最小审批
       流程 161
    9.8 本章小结 162
    第四部分 数据与记忆
    第10章 RAG系统工程 166
    10.1 检索策略全景 166
    10.1.1 两种基础范式 167
    10.1.2 混合检索:BM25 + Dense +
        RRF 167
    10.1.3 SPLADE:可学习稀疏检索 169
    10.1.4 Cross-Encoder重排序 169
    10.1.5 Contextual Retrieval:预处理增强
        检索 169
    10.1.6 向量数据库选型 170
    10.2 Chunking策略 171
    10.2.1 四种策略对比 171
    10.2.2 最优Chunk大小 171
    10.2.3 Late Chunking 172
    10.2.4 “Lost in the Middle” 问题 172
    10.3 Agentic RAG:自适应检索 172
    10.3.1 纠错RAG 172
    10.3.2 Self-RAG:反思Token自适应
        检索 173
    10.3.3 Adaptive RAG:复杂度感知
        路由 174
    10.3.4 A-RAG:层级检索接口 174
    10.3.5 三种模式的Harness集成方式 175
    10.4 RAGAS评估框架 175
    10.4.1 四大核心指标 175
    10.4.2 生产级评估实现 176
    10.4.3 FRAMES基准 176
    10.4.4 RAGChecker:声明级细粒度
        评估 176
    10.5 GraphRAG:突破局部检索限制 177
    10.5.1 标准RAG的根本性局限 177
    10.5.2 GraphRAG四阶段架构 177
    10.5.3 精确实验数据 178
    10.5.4 成本代价 178
    10.5.5 LazyGraphRAG:低成本全局
        推理 178
    10.5.6 LinearRAG:无图构建的全局
        推理 178
    10.5.7 选型决策框架(更新版) 179
    10.6 长上下文vs RAG:架构决策 179
    10.6.1 成本对比 179
    10.6.2 长上下文的性能衰减 180
    10.6.3 决策框架 180
    10.7 RAG生产架构:完整Pipeline 180
    10.8 幻觉缓解与多模态RAG 181
    10.8.1 幻觉缓解三层防线 181
    10.8.2 多模态RAG简述 182
    10.9 实战:从零搭建RAG Pipeline 182
    10.9.1 完整实现 182
    10.9.2 代码解析 185
    10.10 本章小结 185
    第11章 Agent记忆工程 187
    11.1 MemGPT:LLM即操作系统 187
    11.1.1 操作系统类比 187
    11.1.2 两层记忆架构 188
    11.1.3 内存操作工具 189
    11.2 三层记忆模型 189
    11.2.1 三层定义 190
    11.2.2 Generative Agents三维检索 190
    11.3 生产级记忆服务 190
    11.3.1 Zep:Agent专用记忆 190
    11.3.2 Redis Stack:工作记忆 + 语义
        缓存 192
    11.3.3 PostgreSQL + pgvector:统一数据
        平面 192
    11.3.4 Supabase:实时协作记忆 192
    11.3.5 方案选型矩阵 192
    11.4 Prompt压缩:保留信息,
       减少Token 193
    11.4.1 LLMLingua 193
    11.4.2 Context Budget Manager 193
    11.4.3 对话历史管理策略 194
    11.5 OpenClaw记忆模式:Markdown
       即记忆 194
    11.5.1 Claude Code的分层记忆架构 194
    11.5.2 OpenAI的AGENTS.md:导航式
        记忆 195
    11.6 记忆安全:最小暴露原则 195
    11.6.1 记忆隔离 195
    11.6.2 记忆过期 196
    11.6.3 记忆注入防御 196
    11.7 实战:构建分层记忆系统 196
    11.7.1 CLAUDE.md分层记忆模板 196
    11.7.2 简易记忆服务 197
    11.8 本章小结 198
    第五部分 生产实践
    第12章 成本优化工程 202
    12.1 Token经济学 202
    12.1.1 定价结构 203
    12.1.2 Agent任务的Token消耗结构 203
    12.1.3 多模态Token计算 204
    12.2 Prompt Caching:最高杠杆的单点
       优化 204
    12.2.1 工作原理 204
    12.2.2 Anthropic Prompt Caching 204
    12.2.3 生产级实现 205
    12.2.4 缓存工程五原则 206
    12.2.5 缓存预热 206
    12.2.6 缓存失效陷阱 206
    12.2.7 与OpenAI缓存对比 206
    12.2.8 成本节省实例 207
    12.3 Batch API:离线任务的50%
       折扣 207
    12.3.1 适用场景 207
    12.3.2 批处理定价 207
    12.3.3 极限优化:Batch + Cache 208
    12.3.4 生产级批处理 208
    12.3.5 企业ROI计算 208
    12.4 RouteLLM:智能模型路由 208
    12.4.1 核心思想 209
    12.4.2 基准测试数据 209
    12.4.3 四种路由策略 209
    12.4.4 级联路由器实现 210
    12.4.5 路由服务对比 210
    12.5 上下文管理的成本影响 210
    12.5.1 Agent循环中的Token膨胀 210
    12.5.2 压缩策略 211
    12.5.3 工具定义精简 211
    12.6 实战:Prompt Caching成本优化
       实验 211
    12.6.1 实验设计 211
    12.6.2 预期输出 212
    12.7 本章小结 213
    第13章 Agent评估工程 214
    13.1 三层测试金字塔 214
    13.1.1 Agent测试的三层架构 215
    13.1.2 Tier 1:单元测试 215
    13.2 对抗性测试 215
    13.2.1 Prompt Injection抗性测试 215
    13.2.2 Promptfoo红队测试 216
    13.3 LLM-as-Judge:去偏方法论 216
    13.3.1 为什么需要LLM-as-Judge 216
    13.3.2 三大系统性偏差 216
    13.3.3 生产级评估器设计 217
    13.3.4 GPT-4与人类的相关系数(按任务
        类型) 217
    13.3.5 三层评测梯度 217
    13.4 基准测试全景 217
    13.4.1 GAIA:通用AI助手基准 218
    13.4.2 SWE-bench:软件工程基准 218
    13.4.3 SWE-Bench Pro:更难、更抗刷题
        的编码基准 219
    13.4.4 Coding Agent评测:SWE-bench
        与统驭层实证 220
    13.4.5 Terminal-Bench 2.0:终端环境
        编码评估 220
    13.4.6 τ-bench:多轮工具调用
        可靠性 221
    13.4.7 AgentBench:多环境综合基准 221
    13.4.8 基准演进时间线:以GPT-5
        系列为例 222
    13.5 回归检测:统计显著性方法 222
    13.5.1 为什么需要统计显著性 222
    13.5.2 样本量需求 222
    13.5.3 基于Welch’s t-test的回归
        检测 222
    13.5.4 Bootstrap置信区间 223
    13.6 分层CI/CD评测策略 223
    13.6.1 CI/CD集成方案 223
    13.6.2 评估数据集管理 223
    13.7 RAGAS:RAG系统专用评估 223
    13.8 实战:搭建Agent评估套件 223
    13.8.1 LLM-as-Judge评估器 224
    13.8.2 Promptfoo红队测试配置 225
    13.8.3 评估集成建议 226
    13.9 本章小结 226
    第14章 LLMOps工程 228
    14.1 可观测性基座:OTel GenAI语义
       规范 228
    14.1.1 为什么需要专用规范 228
    14.1.2 核心属性表 229
    14.1.3 GenAI四大标准指标 229
    14.1.4 生产级埋点实现 229
    14.1.5 OTel Collector生产配置 231
    14.1.6 可观测性平台选型 231
    14.2 Prompt Registry与版本控制 231
    14.2.1 为什么Prompt需要独立版本
        管理 231
    14.2.2 平台选型 232
    14.2.3 Langfuse实战 232
    14.2.4 MLflow 3.x Prompt Registry 232
    14.2.5 Prompt语义化版本管理规范 232
    14.3 模型生命周期管理 233
    14.3.1 版本固定vs动态别名 233
    14.3.2 模型迁移策略 233
    14.4 实战:为LLM应用接入
       可观测性 234
    14.4.1 OTel埋点:从零记录模型
        调用 234
    14.4.2 Langfuse接入:装饰器式追踪 235
    14.4.3 Prompt版本管理:从硬编码
        到Registry 235
    14.5 本章小结 236
    第六部分 未来展望
    第15章 边界在哪里 238
    15.1 从Vibe Coding到Agentic
       Engineering 238
    15.1.1 一个词的演进史 238
    15.1.2 Vibe Coding的代价 239
    15.1.3 专业工程师的回答 239
    15.1.4 从Cloud Native到Agent
        Native 240
    15.2 Harness标准化的未来 241
    15.2.1 AAIF 241
    15.2.2 OpenClaw与Agent生态 241
    15.2.3 Claude Code Hooks:未来架构中的
        策略执行机制 241
    15.2.4 声明式代理 242
    15.3 AI编程助手生态:Harness的工业级
       验证 242
    15.3.1 规模化证据 243
    15.3.2 框架比模型更重要 243
    15.3.3 OpenAI的统驭工程实践 243
    15.3.4 Stripe Minions的统驭工程
        实践 243
    15.3.5 多Agent并行的协作范式 243
    15.3.6 DORA悖论深化 243
    15.4 统驭的终极命题:七原则的
       回归 244
    15.4.1 从工具到基础设施 244
    15.4.2 七原则的终极意义 244
    15.4.3 写给Harness工程师 244
    15.5 实战:Agent Legibility Score
       自评 244
    15.6 本章小结 246
    附录A 工具与框架速查表 247
    附录B 七原则章节映射矩阵 251
    附录C 关键数据速查 252
    附录D 推荐阅读 254
最新评论共有 0 位网友发表了评论
发表评论
评论内容:不能超过250字,需审核,请自觉遵守互联网相关政策法规。
用户名: 密码:
匿名?
注册