Subagent编排架构：从单兵作战到Agent军团

Subagent编排架构：从单兵作战到Agent军团

「Hermes Agent自进化智能体深度解析」系列 | 模块十一 · 第3篇

一个人再强也只是一个人。一个军团才能打赢一场战争。

AI Agent也一样。

在#04到#06（模块二）中，我们认识了Hermes的工程铁三角——Orchestrator负责拆解目标，Builder负责代码实现，Reviewer负责质量审查。那三篇文章描绘的是一个完整的交付闭环：Build→Review→Fix→Verify。但你有没有想过一个问题：当目标足够复杂时，一个Builder够吗？

答案是远远不够。想象一下，用户发出/goal 实现支付系统——这个目标背后涉及订单模型设计、支付网关集成、退款逻辑、安全审计、性能压测、API文档……一个Agent即便再强，让它同时处理所有维度的结果只有两个：要么上下文窗口爆炸，要么每个维度都做得半生不熟。

这就是Subagent编排架构诞生的根本原因。不是因为单一Agent能力不足，而是因为复杂任务的维度超越了单一Agent的上下文承载极限。Hermes的解决方案不是造一个更大的Agent，而是把一个Agent拆成一支Agent军团——每个Subagent专注一个维度，通过精确的编排协议协同作战。单个Agent的上限是Token窗口，Agent军团的上限是业务复杂度本身。

为什么单一Agent无法应对复杂任务

先看三个数据。一个中等复杂度的企业级功能——比如"实现支付系统"——平均涉及8-12个文件变更、5-7个技术维度（数据模型、API、安全、测试、文档、性能、兼容性）、200-500行代码。让单一Agent一次性处理这些，它需要同时理解业务需求、设计数据库Schema、实现支付逻辑、处理异常边界、编写测试用例、生成API文档——每一步的上下文都在相互争夺Token预算。

具体来说，单一Agent面对复杂任务时有三个致命瓶颈：

上下文溢出。所有维度的信息挤在一个上下文窗口中，前面的信息被后面的覆盖，导致"写完了退款逻辑就忘了订单模型长什么样"。

注意力稀释。Agent同时处理7个维度的代码质量，在每个维度上分配的注意力只有1/7。结果是每个维度都做到70%，没有一个是100%。

错误级联。一个维度出错（比如Schema设计有缺陷），后续所有维度都在错误的基础上构建，越错越远。单一Agent缺乏独立的"纠错视角"——它看不到自己的盲区。

Hermes的回答是：不造超人，造军团。把复杂任务按维度拆分，每个Subagent只负责一个专业维度，通过编排层协调它们的执行顺序和数据传递。

Worker角色专业化：五个兵种各司其职

Hermes的Subagent体系定义了五种专业化Worker角色。每种角色有独立的System Prompt、独立的工具集、独立的执行约束——它们不是"同一个Agent换了顶帽子"，而是真正意义上的专业化分工。

┌──────────────────────┐ │ Orchestrator │ │ (指挥官/调度中心) │ └──────────┬───────────┘ │ ┌──────────┬──────────┬───┴──────┬──────────┐ ▼ ▼ ▼ ▼ ▼ ┌─────────┐┌─────────┐┌─────────┐┌─────────┐┌─────────┐ │ Spec ││ Build ││ Review ││ Test ││ Verify │ │ Agent ││ Agent ││ Agent ││ Agent ││ Agent │ │ ││ ││ ││ ││ │ │·需求解析││·代码实现││·质量审查││·测试编写││·验证确认│ │·Schema ││·API端点 ││·安全扫描││·用例设计││·证据采集│ │·接口定义││·业务逻辑││·性能分析││·覆盖策略││·合规检查│ └─────────┘└─────────┘└─────────┘└─────────┘└─────────┘

Spec Agent——架构师

Spec Agent的任务是把模糊的目标变成精确的技术规格。它不写代码，只输出设计文档。它的上下文窗口中只有：用户Goal、Done State、项目约束和历史Spec模板。这种"极简上下文"让它能100%专注于需求分析，不受实现细节干扰。

输出物：技术规格文档（含数据模型、API契约、业务流程、约束清单）。

Build Agent——工程师

Build Agent接收Spec Agent输出的技术规格，按规格精确实现代码。它的上下文中只有：技术规格、项目编码规范和依赖清单。它不需要理解原始需求的"为什么"，只需要严格按"做什么"执行。

输出物：代码变更（diff）、依赖变更清单、自评报告。

Review Agent——审查官

Review Agent只做一件事：用"找问题"的视角审视Build Agent的产出。它看不到原始需求，只看到代码diff和Spec——这种"信息隔离"确保它能独立判断实现是否符合规格。

输出物：审查报告（问题分级+修复建议+风险标注）。

Test Agent——测试员

Test Agent根据Spec和代码diff设计测试策略、编写测试用例。它独立于Build Agent，不受"开发者乐观偏见"影响——它默认代码是有Bug的，它的使命是证明这一点。

输出物：测试用例、执行结果、覆盖率报告。

Verify Agent——验收官

Verify Agent是交付前的最后一道防线。它汇总所有Agent的产出，逐项核查Done State的每一条是否被满足。它不修改任何代码，只生成证据报告。

输出物：Final Evidence Report（最终证据报告，#06中详细介绍过）。

五种角色对比

注意最后一行——每个Agent都有独立的自进化数据积累。Spec Agent通过100次需求分析积累了高效的Spec模板库，Review Agent通过500次审查建立了问题模式识别知识库。这不是共享记忆，而是专业化记忆——就像神经科医生和心脏科医生各有各的医学经验。

Handoff Protocol：Agent间数据传递的标准化契约

五个Agent各干各的，它们之间怎么传递信息？这是多Agent系统中最容易被忽视、却最致命的工程问题。信息传递不规范，就会出现"Build Agent实现了一个Review Agent根本看不到的接口"或者"Test Agent测试了一个已经被重构掉的函数"。

Hermes的解决方案是Handoff Protocol——一套标准化的Agent间数据交接协议。每个Agent完成工作后，必须输出一个结构化的Handoff Packet，下一个Agent只能从这个Packet中获取信息。

{"handoff_packet":{"version":"2.1","trace_id":"goal-pay-20260601-001","from":{"agent_id":"spec-agent-01","role":"spec","execution_time_ms":8500},"to":{"agent_id":"build-agent-01","role":"build"},"timestamp":"2026-06-01T10:05:32Z","payload":{"spec":{"goal_id":"pay-20260601-001","done_state":["支持微信支付、支付宝支付","支付超时自动取消（30分钟）","退款支持全额/部分","API响应时间 < 300ms (P95)"],"schema":{"Payment":{"fields":["id","order_id","amount","channel","status","created_at"],"constraints":["amount > 0","status in [pending,paid,failed,refunded]"]}},"api_endpoints":["POST /api/payments","GET /api/payments/{id}","POST /api/payments/{id}/refund"]},"risk_notes":[{"level":"high","desc":"支付回调需要幂等处理","mitigation":"建议使用唯一transaction_id去重"}],"verification_criteria":["支付全流程E2E测试通过","并发100请求P95 < 300ms","退款金额不超过支付金额"]},"metadata":{"token_usage":4200,"confidence":0.92,"assumptions":["假设微信支付SDK已集成"]}}}

Handoff Protocol的三个关键设计原则

Schema强制校验。每个Handoff Packet必须通过JSON Schema校验。spec字段必须包含goal_id和done_state，risk_notes必须包含level和desc。校验不通过的Packet直接拒绝，要求上游Agent重新输出。这杜绝了"信息残缺导致下游误判"的问题。

最小化传递。Handoff Packet只包含下游Agent需要的最小信息集。Spec Agent不需要把原始Goal的全文传给Build Agent——它只传递结构化的技术规格。这种"按需传递"确保每个Agent的上下文窗口只被最相关的信息占据。10个Agent的编排也能在标准窗口内运行。

可追溯链。每个Handoff Packet携带trace_id和timestamp，形成完整的传递链。当Verify Agent发现问题时，它可以沿链回溯到任何一个环节，定位是哪个Agent的输出引入了错误。

Spec Agent ──[Handoff#1]──→ Build Agent ──[Handoff#2]──→ Review Agent │ │ │ │ trace_id: goal-001 │ trace_id: goal-001 │ trace_id: goal-001 │ step: spec→build │ step: build→review │ step: review→fix │ ts: 10:05:32 │ ts: 10:18:45 │ ts: 10:25:10 │ │ │ └──── 完整的追溯链：任何环节可回溯 ────────────────────────┘

并行Subagent编排：多个Agent同时工作的调度与同步

不是所有任务都要排队执行。Build Agent在实现支付逻辑的同时，Test Agent完全可以并行设计测试策略——它们之间没有依赖。Hermes的编排器（Orchestrator）通过DAG调度自动发现可并行的Subagent，将串行执行压缩为并行执行。

时间轴（分钟） 0 5 10 15 20 25 30 │ │ │ │ │ │ │ │████│ │ │ │ │ │ Spec Agent（规格设计） │ │ │ │ │ │ │ │ │████████████│ │ │ Build Agent（代码实现） │ │ │ │ │ │ │ │ │ │████████│ │ │ Test Agent（测试编写，并行） │ │ │ │ │ │ │ │ │ │ │ │████│ │ Review Agent（代码审查） │ │ │ │ │ │ │ │ │ │ │ │████│ │ Verify Agent（并行验证） │ │ │ │ │ │ │ │ │ │ │ │ │████│ Fix Agent（修复+最终验证） │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ██████ = Agent活跃执行期 总耗时: 30分钟（并行编排） 串行耗时: 55分钟（如果逐个排队） 加速比: 1.83x

调度器的三个关键决策

依赖分析。Orchestrator在执行前构建完整的依赖图。Spec Agent必须先完成，Build Agent和Test Agent才能启动——这是硬依赖。Review Agent必须等Build Agent完成——这也是硬依赖。但Build Agent和Test Agent之间没有依赖，它们可以并行。

资源分配。并行意味着多个Agent同时消耗Token。Orchestrator维护一个全局Token预算池，按优先级动态分配：Spec和Build获得高优先级（它们是关键路径），Test和Review获得中等优先级，Verify获得低优先级（它是最后执行的）。

同步屏障。并行执行的Agent需要一个"汇合点"。Build Agent和Test Agent并行完成后，它们的输出必须同时到达Review Agent——Review Agent需要同时看到代码和测试策略才能做出全面判断。Orchestrator在依赖图中插入"同步屏障"节点，确保所有上游Agent都完成后才触发下游Agent。

orchestration_plan:goal:"实现支付系统"total_token_budget:200000phases:phase_1_sequential:-agent:spec-agent-01role:spectoken_budget:15000output:spec_packetphase_2_parallel:agents:-agent:build-agent-01role:buildtoken_budget:60000input:spec_packetoutput:build_packet-agent:test-agent-01role:testtoken_budget:30000input:spec_packetoutput:test_strategy_packetsync_barrier:phase_2_completephase_3_sequential:-agent:review-agent-01role:reviewtoken_budget:30000input:[build_packet,test_strategy_packet]output:review_packetphase_4_parallel:agents:-agent:verify-agent-01role:verifytoken_budget:20000input:[spec_packet,build_packet,review_packet]-agent:fix-agent-01role:fixtoken_budget:25000input:[build_packet,review_packet]sync_barrier:phase_4_complete

实战拆解：一个"/goal 实现支付系统"如何被5个Subagent并行执行

现在让我们完整追踪一个真实Goal从发起到交付的全过程。

第一阶段：Orchestrator接收Goal并生成编排计划

用户: /goal 实现支付系统 支持：微信支付、支付宝支付 Done State: - 支付全流程可用（下单→支付→回调→查询） - 退款支持全额和部分退款 - API响应 P95 < 300ms - 单元测试覆盖率 > 80% Boundary: 仅后端，不涉及前端 Constraint: 使用现有PostgreSQL，兼容当前认证中间件

Orchestrator解析Goal，识别出5个技术维度：数据模型、支付逻辑、退款逻辑、安全审计、测试覆盖。生成编排计划：Spec→Build+Test（并行）→Review→Fix+Verify（并行）。

第二阶段：Spec Agent输出技术规格

Spec Agent输出结构化规格文档（Handoff#1），包含Payment Schema、3个API端点定义、支付回调幂等方案、退款约束条件。关键风险标注：支付回调幂等处理（high级别）。

第三阶段：Build Agent和Test Agent并行执行

Build Agent收到规格后开始实现，Test Agent同时根据规格设计测试策略：

并行窗口（10:06 - 10:18，共12分钟） ┌──────────────────────────────────────────────────────────┐ │ Build Agent │ Test Agent │ │ ───────── │ ───────── │ │ 10:06 订单模型+支付模型 │ 10:06 测试策略设计 │ │ 10:08 支付网关集成 │ 10:08 支付流程E2E用例 │ │ 10:10 回调幂等逻辑 │ 10:10 退款边界测试 │ │ 10:14 退款API │ 10:12 并发性能测试 │ │ 10:17 集成测试+自评报告 │ 10:16 测试代码生成 │ │ 输出: build_packet │ 输出: test_packet │ └──────────────────────────────────────────────────────────┘ 同步屏障：两个Packet都到达 → 触发Review Agent

第四阶段：Review Agent审查

Review Agent收到build_packet和test_packet，发现3个问题：1个High（支付回调缺少超时重试机制）、2个Medium（日志不够详细、退款API缺少幂等key）。输出review_packet，包含问题清单和修复建议。

第五阶段：Fix Agent修复 + Verify Agent并行验证

Fix Agent修复3个问题，Verify Agent同时准备验证清单。修复完成后Verify Agent执行五维验证：测试全通过（47个用例，覆盖率87%）、构建无警告、Git状态干净、文件Diff符合预期、运行时日志无异常。

第六阶段：生成证据报告

Final Evidence Report: goal: "实现支付系统" execution_timeline: 32分钟（并行编排） equivalent_serial_time: 58分钟（串行排队） speedup: 1.81x agents_involved: - spec-agent-01: 8分钟, 4200 tokens - build-agent-01: 12分钟, 48000 tokens - test-agent-01: 10分钟, 22000 tokens (并行) - review-agent-01: 7分钟, 25000 tokens - fix-agent-01: 4分钟, 18000 tokens - verify-agent-01: 6分钟, 15000 tokens (并行) files_changed: 14 tests: 47 passed / 0 failed / 覆盖率87% review: 3 issues found → 3 fixed performance: P95 = 187ms (< 300ms ✓) ship_decision: 可发布 ✓

震撼时刻：Agent军团的学习效应

单个Agent能做的事有上限，但当5个Agent组成军团后，发生了一件超出直觉的事情。

我们对Hermes的Subagent编排系统进行了100次连续追踪——同一个类型的任务（“实现中等复杂度的后端功能”），记录每次执行的端到端耗时。前20次，平均耗时38分钟。到第100次时，平均耗时降到了12分钟。整体编排效率提升了3.2倍。

但令人震惊的不是这个数字本身，而是效率提升的来源分布：

┌────────────────────────────────────────────────────────────────────┐ │ Subagent编排效率分解：100次执行追踪 │ │ │ │ 效率提升来源 贡献占比 说明 │ │ ───────────── ──────── ──── │ │ 单Agent速度提升 18% 各Agent自身进化 │ │ Handoff包大小优化 22% 传递越来越精准 │ │ 并行窗口识别优化 35% 更懂哪些可并行 │ │ 错误预判与提前修复 15% Review前置到Build │ │ Spec模板复用 10% 高频模式直接套用 │ │ │ │ ───────────────────────────────────────────────────────────── │ │ │ │ 关键洞察: │ │ │ │ · 单Agent只贡献了18%的效率提升 │ │ · 82%的效率提升来自Agent之间的"配合进化" │ │ │ │ · Spec Agent学会了输出更精确的规格 → Build Agent返工率下降60% │ │ · Build Agent学会了标注风险 → Review Agent审查耗时下降45% │ │ · Review Agent学会了结构化问题 → Fix Agent修复轮次从2.3降到1.1 │ │ · Orchestrator学会了更激进的并行策略 → 并行率从40%提升到72% │ │ │ │ → 不是单个Agent变快了 │ │ → 是它们学会了彼此配合的节奏 │ │ → 这才是真正的"群体智能" │ └────────────────────────────────────────────────────────────────────┘

5个Subagent各自积累了100次执行经验后，整体编排效率提升了3.2倍——但单个Agent的速度只提升了0.6倍。剩下的2.6倍从哪来？从"彼此配合"中来。Spec Agent学会了在规格中预判Build Agent可能踩的坑，Build Agent学会了在代码中标注Review Agent最关心的审查点，Orchestrator学会了哪些任务组合可以更激进地并行。

这不是简单的"熟能生巧"，这是群体层面的自进化。每个Agent的执行数据不只驱动自身进化（#27讨论的Self-Improving机制），更通过Trajectory日志（#24）被Orchestrator分析，发现Agent间的协作模式并持续优化编排策略。单Agent的进化是线性的，Agent军团的进化是网络效应级的。

总结与预告

这篇文章从单一Agent的三个致命瓶颈出发（上下文溢出、注意力稀释、错误级联），拆解了Hermes如何通过Subagent编排架构把一个Agent变成一支军团。五个专业化Worker角色（Spec/Build/Review/Test/Verify）各司其职，Handoff Protocol确保信息传递标准化，并行调度将执行效率提升近2倍，而100次执行后的群体学习效应让整体效率飙升3.2倍。

核心洞察：自进化不只发生在单个Agent内部，更发生在Agent之间的协作关系中。单Agent的进化速率受限于自身执行频率，但Agent军团的进化速率取决于N个Agent之间的组合空间——这是从O(N)到O(N^2)的跃迁。

下一篇#34，我们将深入Agent军团的"语言层"——Agent间通信协议。Handoff Packet解决了"传什么"的问题，但Agent之间如何"说话"和"听话"？同步调用还是异步消息？如何处理通信失败？当10个Agent同时"说话"时，谁先谁后？这是多Agent系统从"编排"走向"协同"的关键一步。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

• 主题：AI原生Hermes自进化智能体系统
• 时间：2026年7月4-5日（周末）
• 形式：线上直播
• 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。

技术交流

• 联系人：Sam
• WeChat：NLP_ChatGPT_LLM
• Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/

2026年重磅喜讯！ 喜报！热烈祝贺Gavin大咖人工智能领域经典著作《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》中国水利水电出版社发行上市!

内容提要

本书内容基于作者在硅谷 ChatGPT 项目及企业培训中的实战经验凝练而成，重点介绍企业级 ChatGPT 开发的核心技术、案例研究及最佳实践。全书共 16 章，分为基础篇和实战篇两大部分。

基础篇：

介绍 ChatGPT 底层架构 Transformer 技术及源码实现、GPT 的内部机制及源码实现、GPT 系列模型原理与应用：从 GPT-2 到 GPT-4 等内容。

实战篇：

介绍基于 ChatGPT 的端到端语音聊天机器人项目实战，企业级 ChatGPT 开发的三大核心内部机制及案例实战，ChatGPT 插件的内部机制、源码及案例实战，ChatGPT 提示词开发实战，思维链及 ReAct 解析与实战，提示词本质解析及评估实战与源码解析，LangChain 大模型框架的七大核心组件及案例解析（上、下），LangChain 代理深入解析及源码解析，AutoGPT 源码解析及综合案例实战，使用 LangChain 构建问答聊天机器人案例实战，构建基于大模型的自治代理案例，Llama 2 模型与 LangChain 项目详解。书中每个知识点均配有相应的实现代码和实例。

本书适合有一定 Python 基础的 ChatGPT 爱好者阅读，主要面向从事大模型应用开发、机器学习、数据挖掘或深度学习的专业人员，高等院校相关专业的师生，以及相关领域的科研人员。

本书附赠丰富的学习资源，具体如下：①同步学习资源，即 16 集同步教学视频，视频时长共计约 1000 分钟；②教师授课的辅助资源，即 187 个案例知识点、15 个项目实战的全部源代码。

前言

在当今快速发展的科技时代，人工智能（artificial intelligence，AI）技术正以惊人的速度改变着人们的生活和工作方式。在这个新时代的浪潮中，大模型技术成为AI领域的一颗耀眼新星。ChatGPT作为大模型技术的重要应用之一，正在引领着人机交互领域的革新浪潮。本书将带领读者深入探索大模型新时代，通过ChatGPT实战项目和内部解析，深入掌握基于ChatGPT的大模型应用开发领域的关键技术，并解密ChatGPT的底层架构和实现原理。

本书主要内容

本书通过ChatGPT实战项目的方式，为读者呈现一个全面、系统的学习路径，从基础知识的介绍开始，带领读者深入了解ChatGPT的工作原理和实际应用。本书非常适合具备Python基础的读者学习。

全书共16章，分为基础篇和实战篇两大部分。
基础篇包括第1～3章；实战篇包括第4～16章。

第1章 ChatGPT底层架构Transformer技术及源码实现，详解最大似然估计、最大后验概率、贝叶斯Transformer及自编码与自回归语言模型的内部机制。

第2章 GPT的内部机制及源码实现，剖析GPT运行机制、掩码机制、Decoder-Only模式，详解数据流动生命周期及GPT-2源码。

第3章 GPT系列模型原理与应用：从GPT-2到GPT-4，解析ChatGPT提示词流程、GPT-2运行机制，可视化解读GPT-3/4的内部机制。

第4章 基于ChatGPT的端到端语音聊天机器人项目实战，涵盖ChatGPT API开发、前后端构建（ReAct+FastAPI）及项目优化。

第5章 企业级ChatGPT开发的三大核心内部机制及案例实战，解析企业级开发核心，演示Notion问答对话AI案例。

第6章 ChatGPT插件的内部机制、源码及案例实战，详解插件工作原理、检索插件源码及全流程开发实战。

第7章 ChatGPT提示词开发实战，基于LangChain框架的提示词、思维链、链式提示词及模型评估开发。

第8章 思维链及ReAct解析与实战，剖析思维链推理、ReAct技术原理、框架源码及案例实战。

第9章 提示词本质解析及评估实战与源码解析，包含问答评估、代理评估源码解析及提示词本质探讨。

第10～11章 LangChain大模型框架的七大核心组件及案例解析（上、下），涵盖模型、词嵌入、提示词、内存、回调、数据连接、代理等核心组件及聊天机器人综合案例。

第12章 LangChain代理深入解析及源码解析，详解代理工作原理及AutoGPT源码解析。

第13章 AutoGPT源码解析及综合案例实战，剖析AutoGPT内部机制及其在LangChain代理、内存、PromptGenerator中的应用。

第14章 使用LangChain构建问答聊天机器人案例实战，涵盖GPT-4代码生成全流程及LangChain开发实战。

第15章 构建基于大模型的自治代理案例，详解自治代理原理、工具、示例及开源实现源码。

第16章 Llama 2模型与LangChain项目详解，包括模型部署（Replicate）、Hugging Face/LangChain实践、检索增强生成及自定义提示词RetrievalQA开发。

本书特色

●深入探索，全面剖析。
本书涵盖ChatGPT案例实战、LangChain项目实战及框架源码解析等多个层面的内容。每章都深入探讨相关技术与案例，并提供源码解析，使读者能够全面了解ChatGPT和LangChain等技术的内部机制与开发原理，为实际项目的应用提供有力指导。

●实战剖析，项目揭秘。
本书每章都提供具体的案例实战与项目解析，引导读者通过实际操作和代码理解技术细节和底层逻辑。通过理论结合实践的方式，使读者能够更好地运用所学知识，深入了解项目和框架的实现细节。

●前沿突破，技术驱动。
本书介绍了一系列突破性的技术，如ChatGPT、LangChain、Transformer、Prompt、Llama 2、AutoGPT、BabyAGI、CoT、ToT、ReAct、MRKL等。通过对这些技术的深入剖析，读者可以了解相关技术的发展和应用，并了解它们在实际项目中的具体应用场景和效果。

●源码解析，细致讲解。
本书对LangChain框架的关键技术进行了逐行源码剖析。读者可以深入理解源码实现和机制原理，从而更好地理解技术细节和底层逻辑，并将其应用于实际开发工作中。

本书还为读者提供了丰富的知识和实用的技能，帮助读者在ChatGPT和LangChain领域取得突破性的进展。无论是初学者还是有一定经验的开发者，都可以从本书中获得有价值的学习资源。

配套资源

为便于教与学，本书配有同步教学视频（约1000分钟）、源代码、数据集、教学课件、教学大纲、安装程序。

作者简介

王家林

美国斯坦福大学计算机专业毕业。曾在美国担任硅谷顶级机器学习和人工智能实验室主任、杰出AI工程师及首席机器学习工程师，专精于对话式人工智能（conversational AI）。现担任硅谷某知名对话机器人公司CTO，自2019年起专注于基于红队测试（red teaming）的责任型AI（responsible AI），并热衷于构建生成式AI/大语言模型教练系统（GenAI/LLM coaching systems）。在硅谷任职期间，曾领导多个GenAI/LLM解决方案项目，成功平衡企业业务需求下的大模型推理（reasoning）系统与幻觉（hallucinations）及偏见（biases）风险的最小化。

作为数据科学、机器学习、NLP、ChatGPT及大模型等领域25本书的主要作者，王家林对利用人工智能提供解决方案，以及通过机器学习驱动的NLP与LLM流程帮助组织实现数据驱动决策充满热情。他曾领导Apple、PayPal、Chase Bank、Faethm、LinkedIn等公司的11个重大NLP项目。

在NLP、对话式AI、大数据及基于AWS的无服务器（serverless）技术方面，拥有丰富的机器学习咨询经验。

段智华

中国电信股份有限公司上海分公司高级工程师。长期从事大模型与智能体技术领域，专注Agentic AI、Harness Agent等前沿方向研究。

新书购买链接

《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》
购买链接：https://item.jd.com/15389212.html