很多 Agent 框架把系统提示当成"一坨文本"拼出来就发给模型，结果每轮调用都在变：上轮记忆写回、当前目录变更、插件塞了一段上下文……提示前缀每变一次，Anthropic/OpenAI 的 prompt cache 就失效一次，账单与首 token 时延一起涨。
Hermes Agent（http://github.com/NousResearch/hermes-agent）在 与 中明确把"缓存的系统提示"和"API 调用时的临时叠加"分开。官方 Prompt Assembly 一节开宗明义：Hermes deliberately separates cached system prompt state from ephemeral API-call-time additions.
本篇按官方文档与目录结构，拆出这条边界是怎么落地的，以及为什么 、、、技能索引、平台提示各自该放在哪一层。
缓存的系统提示按 三层依次拼接（见 ）：层内容是否参与长前缀缓存stable身份（SOUL.md 或 DEFAULT_AGENT_IDENTITY）、工具/模型行为指引、编码简报是context调用方 system_message、项目上下文文件（.hermes.md/AGENTS.md/CLAUDE.md/.cursorrules）、worktree 依赖的 git 工作区快照、运营者指令与平台提示是（共享项目文件前置在 worktree 行之前）volatile技能索引、MEMORY.md 快照、USER.md 用户画像快照、外部记忆提供者块、时间戳/会话/模型/提供者行、运行环境提示（host/home/cwd）前缀尽量稳定，尾部放易变项
关键设计点：上下文层里"项目共享文件"必须排在"当前 worktree"之前。同一个项目在不同 git worktree 跑的两个会话，会共享覆盖整个 context 块的前缀，这正是最长前缀 provider cache 复用的边界。runtime 块恒定放在 volatile 末尾。
里的 读 边界后的第一段主机信息，末尾以一个收尾标记与"把标题写进正文"的旧式 prose 区分。模型/提供者在 runtime 边界之前读取。 字段故意不当成身份字段：desktop ↔ TUI 切换时缓存字节不变，当前 surface 的指令以一次性附注形式注入 per-turn 用户消息通道（见 ，对应 issue #104414）。
下列内容只在调用 API 时临时拼上去，不写回缓存系统提示：prefill 消息网关派生的 session context overlay后续轮次注入到当前轮用户消息的 Honcho/外部召回结果 插件返回的 context（拼到当前轮 user message，而非系统提示）
加载成功后，替换硬编码 ，并调 避免 SOUL.md 既当身份又当上下文文件出现两次。子代理委派设 时走 ，不读 SOUL.md。
用"first match wins"优先级，只加载一种：优先级文件搜索范围说明1.hermes.md / HERMES.mdCWD 向上至 git rootHermes 原生项目配置2AGENTS.mdCWD only通用 Agent 指令3CLAUDE.mdCWD onlyClaude Code 兼容4.cursorrules / .cursor/rules/*.mdcCWD onlyCursor 兼容
所有上下文文件都做：安全扫描（不可见 unicode、ignore previous instructions、凭据外泄模板）、按 70/20 头尾切分截断（下限 20k 字，上限 500k 字， 的 强制覆盖）、YAML frontmatter 剥离。
优先于 ；裸字符串等价于 ；畸形项被防御性忽略，回退到默认。系统提示构建时一次性解析（session 起点与压缩重建时），对固定配置产生字节稳定提示，属 stable 层，不破坏缓存。
启动 Hermes 后跑一次 debug：
重点看： 边界是否在 SOUL/context/memory/skills/plugin 全部之后； 行是否被排除在身份字段外；cwd 是否真的落在 volatile 末尾。
官方文档明确： 是实现代码，不是配置面。优先改输入面：想要的效果应改的位置不同 Agent 人格~/.hermes/SOUL.md仓库级工作规则.hermes.md / AGENTS.md / CLAUDE.md / .cursorrules可复用操作流程新增/修改 skill，不动核心代码部署特有指令config 的可选 system_message 或 API override单轮范围提示HERMES_EPHEMERAL_SYSTEM_PROMPT 或 prefill
只有当你 fork 维护或贡献上游行为时，才动 。
复刻官方校验：读首段 runtime host 信息 + 末尾闭合标记，对比模型/provider 是否在边界之前；不一致就触发重建。不要把记忆写进 stable 层：/ 故意放 volatile 层，会话中途写盘不会立即改缓存提示；只有显式重建路径（新会话或压缩触发）才刷新。强行把记忆塞 stable 层会让缓存前缀频繁失效。平台切换不要重建提示： 不是身份字段。desktop ↔ TUI 切换走 的一次性用户消息附注，缓存字节保持不变（#104414）。 只读 CWD：不要在子目录放 期望向上查找；只有 会向上走到 git root。子目录提示走 的渐进发现。 插件 context 不进系统提示：它拼到当前轮 user message，Hermes 自动拼接多插件返回块。误把它当系统提示处理会破坏缓存前缀。平台提示覆写错配置不会炸：畸形项被防御性忽略并回退默认，不会跨平台泄漏；但 与 同时存在时 全赢，配置时不要混用。子代理没 SOUL.md： 时走 ，不要在委派任务里期望子代理继承你写的 SOUL.md 人格。不要直接改 ：那是全局产品变更，不是 per-user 定制面；要么改输入面（SOUL.md/skills/config），要么按上游贡献流程发 PR。官方文档 Prompt Assembly: https://hermes-agent.nousresearch.com/docs/developer-guide/prompt-assembly官方仓库: https://github.com/NousResearch/hermes-agent关联 Context Compression & Prompt Caching: https://hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching关联 Session Storage: https://hermes-agent.nousresearch.com/docs/developer-guide/session-storage关联 Gateway Internals: https://hermes-agent.nousresearch.com/docs/developer-guide/gateway-internals
思维链提示（Chain-of-Thought Prompting）是推理时扩展中最简单也最实用的技术之一。它不需要修改模型权重，不需要额外训练，只需要在提示词末尾追加一句指令，就能让模型从直接给答案转向逐步推理。本博客基于本系列博客第4章的翻译内容，讲解思维链提示的实现方式、效果以及背后的原理。
在第3章的设置中，基础模型对数学题 采用贪婪解码，直接输出 ——错误答案。模型在没有任何推理过程的情况下"猜"出了一个结果。
思维链提示的做法极其简单：在原始提示后追加一条指令，要求模型逐步解释。原文使用的是 ，因为该表述在实验中表现良好且保持示例简洁：
模型这次输出的回答包含了完整的方程建立、两边同乘 2 消分母、移项求解等步骤，最终正确得出 ，即 。
思维链提示的原始论文（Kojima et al., 2022）使用的是 。但不同的表述在不同的模型和任务上效果可能不同。原文选择 的原因很直接——在为本章所做的实验中表现良好，且保持了示例的简洁性。
这并不是一个可以忽视的细节。提示词工程中，微小的措辞变化有时会带来可观的准确率差异。在实际应用中，针对具体模型和任务做少量对比测试是值得的。
思维链提示很好地展示了推理时扩展的权衡本质。模型现在回答正确了，但消耗了比之前多得多的词元。LLM 一次生成一个词元，每个额外的词元都需要模型进行另一次前向传播。这些中间推理步骤不仅使回答更长，还直接增加了延迟、计算成本，以及通常还有 API 成本。
在 MATH-500 数据集上的实验结果更清晰地展现了这一权衡：方法模型准确率时间基线（贪婪解码）Base15.2%10.1 min思维链提示（CoT）Base40.6%84.5 min
准确率从 15.2% 提升到 40.6%，代价是运行时间从 10.1 分钟增至 84.5 分钟。这是一个几乎 3 倍的准确率提升，但计算时间也是原来的 8 倍。
思维链提示并没有为模型提供新知识，而是改变了模型使用已有知识的方式。它在实践中有两个方面的帮助：
第一，逐步推演给了模型更多自我纠错的机会。直接给出答案时，模型只有一次"判断"的机会；而逐步推理时，每个中间步骤都可以在一定程度上被后续步骤修正。
第二，逐步推理与许多训练样本的编写方式相匹配。大型数学和逻辑数据集通常包含详细的解题过程，要求思维链可以使模型与其已学到的模式保持一致。
需要指出的是，思维链推理并不能保证正确性。在简单问题上，它有时甚至会降低模型的表现——模型可能生成错误的解释并误导自己，这种现象被称为"过度思考"（overthinking）。此外，经过训练的推理模型（如 Qwen3 的 reasoning 变体）已经在回答中自带解释，不需要也不会从此类思维链提示中受益。
思维链提示是推理时扩展技术的起点：一句追加指令带来显著的准确率提升，但也伴随着词元消耗和运行时间的增加。后续博客将从另一个维度——温度缩放与采样控制——继续探索如何在不改变模型的前提下提升推理能力。没人会在生产服务器上每五分钟手动敲一遍 。Autovacuum 就是那个替你跑 VACUUM 的守护进程。它有一个启动器、最多几个 worker、一套基于代价的节流模型、一个决定"该 VACUUM 谁"的简单公式。这一篇拆开 Autovacuum 的黑盒，把你需要知道的内部机制讲清楚——尤其是那个最容易被人误读的 。
Autovacuum 是对"在一张有上千张表的数据库上，谁来跑 VACUUM？“这个问题的回答。没人会每五分钟在生产服务器上敲一次 。Autovacuum launcher 是一个 Postgres 后台进程，它醒来、检查每个数据库里的每张表、决定哪些需要 VACUUM、然后派发 worker 去干活。默认值是保守的，数学是平易近人的，失败模式就是"Autovacuum 跟不上你的写速率”。
每个集群有一个 launcher。它持续运行，两个周期之间睡眠 （默认 1 分钟）。每次醒来，它挑一个数据库，检查里面的表，要么什么都不做、要么启动一个 worker 去真正 VACUUM。
同时运行的 worker 最多有 个（默认 3）。每个 worker 一次只处理一张表。如果你有十张表需要 VACUUM、却只有三个 worker，七张表就要排队。大表会阻塞小表。 一张 100 GB 表的 VACUUM 要花几小时；一张 10 MB 表的 VACUUM 只要几秒。三个 worker 时，三张大表就能把全部 worker 占满，让小表在大表跑完之前一直没人 VACUUM。
在现代硬件上，三个 worker 太少了。在一张有上百张表和严肃写流量的数据库上，六到十个 worker 更现实。调高 需要重启，所以它更多出现在计划维护清单上、而不是紧急工单里。
针对每张表，每个 周期，Autovacuum 检查一个条件：
就这个。当死元组数超过一个基础阈值加上估计行数的一个比例时，这张表就被 VACUUM。这里的行数估计是 （由 或 更新），不是——后者是一个累计计数器，在繁忙表上可能显著偏离。默认值：
对于一张一百万行的表，就是 50 + 0.2 × 1,000,000 = 200,050 条死元组才会触发 Autovacuum。在每秒一千次更新的速率下（假设没有 HOT 更新），阈值每三分半钟被命中一次。每秒一万次更新时，每二十秒一次。HOT 更新若被原地修剪，不计入 ，所以以 HOT 为主的工作负载要慢得多才达到阈值。这张表在每次 VACUUM 之间会累积二十万条死元组。
那个 0.2 缩放因子是会随表长大而坏掉的部分。 在一张有一亿活行的表上，阈值就是两千万条死元组。两千万条死元组在热点表里意味着，两次 VACUUM 之间就是几十 GB 的膨胀。默认值是假设小表来设计的。大表需要一个更小的缩放因子——通常要小一个数量级。analyze 也有一套平行的旋钮，它跟 VACUUM 一起跑，更新 ：
analyze 跑得比 VACUUM 更频繁（缩放因子更低），而且便宜得多（它只采样表的一部分，而非全表读取）。规划器需要新鲜统计信息来做出好计划，analyze 是唯一更新它们的方式。一张上周就没被 analyze 过的表，意味着规划器正在用过时的直方图做决策。
Autovacuum 并非全速运行。它使用一种基于代价的延迟模型，目的是节流 VACUUM 的 I/O，使其不与前台查询争抢。每次读或写一个页都被赋予一个代价；一旦累计代价超过 ，worker 就睡眠 毫秒，然后重置计数器。
相关旋钮：（从共享缓冲区读一页的代价）（从 OS 缓存读一页的代价）（脏化一个将要被写的页的代价）（每轮代价预算）（轮间睡眠）
算下来，每个 worker 默认的 I/O 预算大约是每秒 40 MB 脏写：每轮 10 个脏页，每秒 500 轮，乘以每页 8 KB。在一个能持续 2 GB/s 的 NVMe 存储数据库上，单个 Autovacuum worker 只用了大约 2% 的可用吞吐。这就是那些保守的默认值——为十五年前的机械硬盘设计的，今天仍在配置文件里。警告默认的 是在 Postgres 13 里从 20ms 改过来的。在旧的 20ms 延迟下，算出来大约是每 worker 4 MB/s，慢了十倍。如果你在管一个从没升级过这套设置的老系统，检查当前值：。如果是 20ms，Autovacuum 就被节流到了大约 4 MB/s 的写。这对任何真正的生产系统都不够。
修复办法是提高 （每轮睡眠前干更多活）或降低 （更短的睡眠）。在现代化服务器上， 加上 可以给到每 worker 约 400 MB/s 的脏写。
但默认情况下，所有 Autovacuum worker 共享全局的 预算。三个 worker 同时跑时，每个 worker 的有效预算大约是总数的三分之一。要让某个 worker 拿到全部预算，可以通过 在表级别设置——该表的 worker 就获得自己的独立预算，而不是切分全局的。
是 Autovacuum 中被误读最多的设置。它不代表"对同一张表的两次 VACUUM 之间间隔一分钟"。 它代表的是"每分钟把 launcher 唤醒一次四处看看"。launcher 然后依次检查每个数据库，按需派发 worker。在一个有二十个数据库的集群上，每个独立数据库大概每二十分钟才被检查一次。
如果你想让热点表被更频繁地检查，答案不是降低 naptime。答案是按表设置 Autovacuum 参数——无论 naptime 是多少，每轮都会检查这些表级设置。把热点表的 ，launcher 会在它一越过 1% 死元组的瞬间就派发 worker。这远比摆弄全局 naptime 响应得快。
暴露了 Autovacuum 上一次触及每张表的时间点：
是该表最近一次 Autovacuum 的时间戳。如果它在一张 正在上升的表上是 NULL 或几小时前的旧值，那就是 Autovacuum 要么被禁用了、要么被一个长事务阻塞了、要么正在输给你写速率的赛跑。 是自启动以来 Autovacuum 处理该表次数的累计值；跨表比较这个数字，能告诉你守护进程把预算花在了哪些表上。launcher 还会在 被设置时把决策写进日志：
现在每一个耗时超过一秒的 Autovacuum 都会写一条日志，包含表名、耗时、扫描页数、移除元组数、可见性映射更新。在繁忙数据库上，这是你能做的最有用的日志改动——没有之一。
Autovacuum 的内部机制其实不复杂：一个 launcher 周期性醒来，用一条公式判断哪些表需要 VACUUM，派发 worker 去干活，worker 用基于代价的模型自我节流以免打断前台查询。真正容易出问题的地方有三个：worker 太少（大表霸占全部）、代价预算太低（为机械硬盘设计、在 SSD 上太保守）、以及那个被误读的 naptime。
记住这一篇最重要的一句话：想让热点表被更快 VACUUM，不要去动 naptime，去把该表的 调低。
下一篇我们进入实战：如何在集群级别和按表级别调优 Autovacuum，以及如何用 pgstattuple 和 pg_stat_user_tables 及早发现膨胀。
下一篇： [066 - Autovacuum 调优与膨胀检测](066-Autovacuum 调优与膨胀检测.md)
Q1： 文章说"没那么重要"，我看到的很多博客第一件事就是调这个参数，到底谁说的对？
很多博客给出的建议是"把 naptime 从 1 分钟调到 10 秒"，以为这样 autovacuum 会跑得更勤快。但实际上 naptime 控制的只是 launcher 醒过来的频率——而决定"这张表什么时候该被 VACUUM"的是 scale_factor 和 threshold 那套公式。即使你把 naptime 设成每秒一次，如果 scale_factor 是 0.2（20%），一张 1 亿行的表仍然要累积 2000 万死元组才会触发 VACUUM——launcher 每 10 秒看一眼、看到的仍然是"还差得远"，继续睡觉。反过来，如果你把这张表的 scale_factor 调成 0.01（1%），launcher 在下一次醒来（可能是一分钟后）就会发现"行了，得开工了"，然后派 worker。所以真正决定"VACUUM 快不快"的是阈值公式，不是唤醒频率。文章建议的 30 秒 naptime 是一个合理的缩短，但不要把它当成银弹。真正有效的做法是：热点表用 让阈值足够低，naptime 保持 30 秒到 1 分钟即可。这不是"哪个对"的问题，而是这两个参数管的是不同层面的事。
Q2：文章说默认的 I/O 预算为机械硬盘设计，我现在的数据库用的是 NVMe SSD，不调整成本会有多大影响？
这个影响是隐形的、但非常真实。默认值 配合默认 ，每个 autovacuum worker 大约只有 40 MB/s 的写磁盘带宽。NVMe SSD 的写带宽通常在 1-3 GB/s——你数据库的硬件能跑 2GB/s，但 autovacuum 只用到了 40MB/s，只用了大约 2% 的硬件能力。这就好比你的数据库硬盘是高速公路，autovacuum 在上面开手扶拖拉机。结果是什么？一张 500GB 的表，死元组比例到了触发阈值，autovacuum 被唤醒，但它需要好几天才能扫完这张表——而在这几天内，表上的更新继续产生新的死元组。autovacuum 变成"永远跑不够快的清洁工"——它一刻不歇，但永远追不上增量。文章建议的 （配合 2ms delay）把带宽提到约 400 MB/s per worker——仍然只用了 SSD 的一部分能力，但已经能让大多数场景下 autovacuum 跑得比写入快。如果你的磁盘确实非常快（比如 Amazon RDS io2 或本地 NVMe），甚至可以提到 4000 或更高——配上 6 个 worker，总共约 2.4 GB/s 的 VACUUM 带宽。
Q3：公式 看起来简单，但它为什么会让大表在两次 VACUUM 之间膨胀到几十 GB？
因为 scale_factor 是和表的大小成正比的。默认的 scale_factor 是 0.2，对于一张 100 万行的表，阈值大约是 20 万死元组——尚且算合理。但对于一张 1 亿行的表，阈值就是 2000 万死元组。假设每行平均 200 字节，2000 万条死元组就是 4GB 的纯垃圾数据，在你的 UPDATE/DELETE 速率下只花几分钟就达到了——但实际上产生这么多死元组的同时，活元组之间还穿插着碎片、索引里多出了 2000 万个指向无效位置的指针、可见性映射被修改了 2000 万次。总体膨胀远不止 4GB，可能是 40GB。然后 autovacuum 被触发，用着 40MB/s 的带宽开始扫描 1 亿行，在你等待它完成的几个小时里，新的死元组继续产生——所以它永远比写入慢。修法是双向的：一方面降低 scale_factor 让阈值更敏感（比如 0.01，意味着 100 万死元组就触发）；另一方面提高代价预算让 VACUUM 跑得更快。两者配合，死元组从"累积到 2000 万再清"变成"累积到 100 万就清"，每次 VACUUM 更快、更频繁，但膨胀总量小百倍。本文是「OpenAI Frontier 深度解析」系列的第 08 篇，也是系列的收官之作。在前七篇中，我们从产品定位、商业价值、四大支柱讲到了五层架构的底下四层。今天，我们登上架构的最顶层——记忆与学习系统，看看 Frontier 的智能体是如何越用越聪明的。
先问你一个问题：一个刚入职的新员工，和一个在公司干了三年的老员工，最大的区别是什么？
是能力吗？不一定——新人可能更聪明、更有冲劲。
是知识吗？也不完全是——很多知识新人也能快速学到。
真正的区别在于经验。
老员工见过更多的场景，踩过更多的坑，知道什么情况下该怎么处理，知道哪些事情看似重要实则无关紧要，知道哪些坑绕不过去、哪些捷径可以走。这些东西，不是书本上能学到的，必须靠时间和经历一点点积累。
AI 也是一样。
一个"刚上岗"的 Agent 和一个"干了一年"的 Agent，如果底层模型是同一个，那它们的基础能力差不多。但真正用起来，差距可能非常大——因为后者有经验、有记忆、有学习。
这就是记忆与学习系统的价值：让 Agent 从"新兵"变成"老兵"，越用越聪明，越用越值钱。
它是 Frontier 五层架构的最顶层，也是整个平台"复利效应"的来源。
Frontier 的记忆与学习系统，不是一个单一的模块，而是一个三层的记忆体系。每一层的作用不同、生命周期不同、影响范围也不同。
从下往上：任务记忆是最基础的，记录每一次任务执行的完整过程组织记忆是沉淀下来的知识，供所有 Agent 共享使用学习闭环是进化机制，让整个系统持续变得更好
下面，我们逐层展开。
任务记忆（Episodic Memory）是最基础、最具体的记忆。它记录的是单次任务执行的完整上下文。
“Episodic"这个词来自认知心理学，意思是"情景记忆”——就是你对某件具体事情的回忆，比如"我昨天下午三点在咖啡馆和朋友喝咖啡"。情景记忆是具体的、有时间地点的、有细节的。
Agent 的任务记忆也是一样。它不是抽象的知识，而是具体的"某次任务的完整记录"。
一次任务的完整记忆，可能包含以下内容：
信息量非常大。为什么要记录这么多？因为这些数据是后续学习和优化的基础——没有详细的过程记录，就不知道该学什么、该怎么改进。
任务记忆有三个主要作用：
1. 上下文保持
在任务执行过程中，Agent 需要记住之前做了什么、得到了什么结果，才能继续下一步。任务记忆提供了这种"短期记忆"能力。
比如，处理一个客户投诉，Agent 第一步查了客户信息，第二步查了订单记录，第三步要根据前两步的结果做决策——这就需要任务记忆把前两步的结果保存下来。
2. 可追溯性
任务结束后，如果有人问"这个结果是怎么来的"，可以通过任务记忆完整回溯整个过程。这对于审计、排错、争议处理都非常重要。
3. 学习素材
任务记忆是组织记忆和学习闭环的"原材料"。每一次任务执行的经验，都可能沉淀为组织知识，或者用于优化 Agent 的行为策略。
任务记忆不是永久保存的。它的生命周期和任务绑定：执行中：活跃状态，Agent 可以随时读写完成后：归档状态，保留完整记录，用于审计和学习一段时间后：可以做摘要或脱敏处理，减少存储成本到期后：根据企业的数据保留政策，可以删除或归档到冷存储
具体保留多久，取决于企业的合规要求和业务需要。财务相关的任务可能需要保留 5-7 年，普通的客服对话可能只需要保留 3 个月。
如果说任务记忆是 Agent 的"个人笔记"，那么组织记忆（Organizational Memory）就是企业的"公共知识库"。
它是从大量的任务执行中，提炼、沉淀出来的结构化知识。所有 Agent 都可以访问和使用组织记忆，站在"前辈"的肩膀上工作。
组织记忆不是简单的"任务记录合集"，而是经过提炼和加工的知识体系。它可能包含：
企业里有各种各样的业务规则——退款政策、审批流程、定价策略、服务标准……这些规则可能散落在各个文档里，也可能只存在于老员工的脑子里。
组织记忆把这些规则结构化地保存起来，Agent 可以随时查询和引用。
比如：“VIP 客户的退款申请，5000 元以内可以由客服主管审批”“电子产品 7 天无理由退货，15 天质量问题换货”“涉及法律风险的问题，必须转交给法务部门处理”
从大量成功的任务执行中，提炼出"怎么做效果最好"的模式和方法。
比如，客服 Agent 发现：“对于情绪激动的客户，先表达共情，再讲解决方案，客户满意度提高 30%”“退款请求如果在 10 分钟内处理完，客户复购率提高 15%”“客户投诉如果在第一次沟通中就解决，后续升级率降低 60%”
这些最佳实践，不是写在 SOP 里的死规则，而是从实际数据中总结出来的、经过验证的有效方法。
常见的问题和对应的解决方案。新 Agent 上来就可以用，不需要从零开始摸索。
和普通的 FAQ 不一样，组织记忆中的问题库是动态更新的——新的问题模式会被自动发现和补充，过时的解决方案会被自动标记和更新。
成功的经验很重要，失败的教训也很重要。
组织记忆会记录常见的失败模式——哪些情况下 Agent 容易出错、哪些操作容易出问题、哪些场景需要特别小心。
比如：“涉及跨境转账的操作，出错率比普通操作高 5 倍，必须人工审核”“客户同时提到多个问题时，Agent 容易遗漏，建议分步骤处理”“超长文档的摘要，容易遗漏关键细节，建议分段处理”
知道"哪里容易踩坑"，和知道"怎么把事做好"同样重要。
企业的业务实体信息——产品、客户、员工、流程、政策……这些信息的结构化表示。
这部分和语义层的知识图谱有重叠，但侧重点不同：语义层的知识图谱侧重于"数据结构"——实体之间的关系、数据来源、属性定义组织记忆的实体知识库侧重于"业务知识"——怎么用、什么场景、常见问题、最佳实践
组织记忆的核心价值是知识复用。
没有组织记忆的时候，每个 Agent 都是"从零开始"——它只有基础模型的通用知识，对企业的具体业务一无所知。每个 Agent 都要自己摸索、自己踩坑、自己成长。
有了组织记忆之后，新 Agent 一上岗就能用前辈们积累的知识。它不需要再犯别人犯过的错，不需要再走别人走过的弯路，一上来就有"资深员工"的水平。
这就是知识的复利——一个 Agent 学到的东西，所有 Agent 都能受益。100 个 Agent 工作一天，积累的经验相当于 100 天的经验。
组织记忆不是自动冒出来的，它需要一个从"任务记忆"到"组织记忆"的提炼过程：
这个过程中，AI 负责"发现和提炼"，人类负责"审核和把关"。两者结合，既保证了效率，又保证了质量。
如果说任务记忆是"记录"，组织记忆是"沉淀"，那么学习闭环（Learning Loop）就是"进化"。
它是整个记忆与学习系统中最核心、也最有价值的部分——因为它让整个系统有了自我改进的能力。
简单说，学习闭环就是：Agent 执行任务 → 产生结果 → 收集反馈 → 优化 Agent → 再执行任务，这样一个不断循环的过程。
每循环一次，Agent 的能力就提升一点。循环次数越多，Agent 就越聪明。
这听起来是不是很熟悉？没错，这就是企业版的 RLHF（基于人类反馈的强化学习）。
在 ChatGPT 中，RLHF 是由全球数百万用户共同完成的，训练出来的是通用能力——让模型更懂人类的意图、更会说人话、更符合人类的价值观。
但在 Frontier 中，RLHF 是在企业内部完成的，训练出来的是企业专属能力——让 Agent 更懂你的业务、更符合你的流程、更适应你的风格。
学习闭环的关键是反馈。没有反馈，就没有学习。反馈的来源主要有三个：
人类用户明确给出的评价。比如：“这个回复很好”“这个方案不对，应该这样改……”“这个 Agent 处理得不好，重新来”
显式反馈的质量最高，但数量最少——因为人不会每次都给评价。
从用户的行为中推断出来的反馈。比如：用户采纳了 Agent 的建议 → 正面反馈用户修改了 Agent 的输出 → 负面反馈（而且还能知道改了什么）用户重复问了同一个问题 → Agent 之前的回答不好用户直接跳过了 Agent 的建议 → 负面反馈
隐式反馈的质量不如显式反馈，但数量要多得多——用户的每一次操作都是隐式反馈。
从任务的最终结果来判断 Agent 做得好不好。比如：客户投诉处理后，客户满意度评分高 → 正面反馈财务报表一次通过审核 → 正面反馈销售报价被客户接受 → 正面反馈客户再次投诉同一个问题 → 负面反馈
结果反馈最接近"业务价值"，但归因最难——结果好不好，不一定完全是 Agent 的功劳或过错，可能还有其他因素。
这三种反馈各有优缺点，在学习闭环中是结合使用的：显式反馈用来做"高质量的学习样本"隐式反馈用来做"大规模的行为学习"结果反馈用来做"最终的效果验证"
学习闭环的完整流程大致是这样的：
这个闭环每转一圈，Agent 的能力就提升一点。而且，随着 Agent 处理的任务越来越多，反馈数据越来越丰富，学习的速度会越来越快、效果会越来越好——这就是复利效应。
学习闭环中的"学习"，不是只有一种方式。根据学习的深度和规模，可以分为不同的层次：学习层次内容所需数据量效果成本Prompt 优化优化提示词、指令模板少（几十条）小，但见效快低检索增强（RAG）更新组织记忆中的知识中（几百条）中等，知识更新中策略优化优化 Agent 的决策策略中（几千条）较大，行为改进中高模型微调微调企业专属模型大（几万条以上）大，能力提升高
不是所有企业都需要做模型微调。对大多数企业来说，Prompt 优化 + RAG + 策略优化就足够了。模型微调虽然效果最好，但成本最高、风险也最大——微调不好可能会把模型调"坏"。
Frontier 的学习闭环应该是分层的——先用低成本的方式优化，如果效果不够，再逐步升级到更高层次的学习。
讲到学习和微调，就不得不提一个非常重要的问题：数据安全和隐私。
企业把数据交给 OpenAI 来训练专属模型，会不会导致数据泄漏？A 企业的学习成果，会不会被 B 企业用到？
这是企业最关心的问题之一，也是 Frontier 必须解决的信任问题。
OpenAI 在这个问题上的立场非常明确：严格的数据边界。
具体来说：
每家企业的数据和学习成果，都是完全隔离的。A 企业的任务记忆、组织记忆、学习成果，B 企业完全看不到，也用不了。
就像每家公司都有自己的员工培训体系一样——A 公司的培训成果，不会自动跑到 B 公司去。
如果企业选择做模型微调，微调是在企业自己的数据上做的，微调后的模型也是企业专属的。这个模型不会被其他企业使用，也不会影响基础模型。
换句话说，企业对自己的学习成果拥有所有权。OpenAI 只是提供工具和平台，不占有企业的知识资产。
Frontier 的学习系统满足各种合规要求——GDPR、SOC 2、ISO 27001 等等。企业的数据在哪里、被怎么用、用了多久，都有完整的记录和控制。
这一点非常关键。因为只有企业相信自己的数据是安全的、自己的知识资产不会被拿走，它才敢把核心业务交给 AI。
学习有没有效果，不能靠感觉，得有量化的评估。
Frontier 的记忆与学习系统，配套了一套完整的评估框架。它可以从多个维度衡量 Agent 的表现，追踪学习效果。
常见的评估维度包括：
有多少任务被成功完成了？成功率是上升还是下降？
这是最基础的指标。但光看成功率不够——因为简单的任务成功率高，难的任务成功率低。如果 Agent 只挑简单的做，成功率会很高，但价值不大。
完成的任务中，结果的质量怎么样？可以从多个角度衡量：准确性：结果对不对？完整性：有没有遗漏？合规性：符合企业政策吗？用户满意度：使用的人满意吗？
完成一个任务平均需要多长时间？消耗了多少资源？
效率很重要。AI 的价值很大程度上来自效率提升——如果 AI 干得比人还慢，那就没有意义了。
有多少任务是 Agent 自主完成的？有多少需要人工介入？人工介入率是上升还是下降？
自主程度是一个很重要的指标。它直接反映了 Agent 的"成熟度"——越成熟的 Agent，需要人工介入的比例越低。
完成单位任务的成本是多少？成本是在上升还是下降？
成本效益 = 产出价值 / 投入成本。这是最接近 ROI 的指标。
这些指标不是零散的，而是通过一个统一的评估仪表盘来展示。管理者可以在仪表盘上看到：每个 Agent 的表现怎么样每个部门的 AI 应用效果如何整体的 AI 投资回报率是多少学习进步的速度怎么样哪些地方还需要改进
仪表盘的意义不只是"看数据"，更重要的是管理——你可以根据数据来决定：哪些 Agent 需要更多的训练哪些场景的 AI 应用效果好，可以扩大哪些场景效果不好，需要调整或暂停投资应该往哪个方向倾斜
除了看"好的方面"，评估框架还要分析"不好的方面"——失败模式分析。
Agent 常见的失败模式有哪些？哪些任务最容易失败？失败的原因是什么？（理解错误？知识不足？工具不好用？策略不对？）失败造成的影响有多大？怎么改进才能减少失败？
失败模式分析是学习闭环的重要输入——知道哪里错了，才能知道往哪个方向改进。
很多人会把"学习闭环"和"模型微调"混为一谈。其实它们不是一回事。
我们来梳理一下它们的区别：维度学习闭环（在数据边界内学习）模型微调（改变模型本身）核心方式通过 Prompt、RAG、策略优化来改进通过更新模型参数来改进数据要求少量到中量数据即可需要大量高质量数据效果范围主要改进行为和知识，基础能力不变可以改进基础能力成本低到中等高风险低，出问题容易回滚高，可能影响整个模型数据边界数据完全留在企业内需要把数据用于训练迭代速度快，可以实时调整慢，需要训练周期适用场景业务流程优化、知识更新能力升级、风格统一
简单说：学习闭环是"改进工作方法"——人还是那个人，但工作方式更高效了、经验更丰富了模型微调是"提升个人能力"——人变得更聪明了、能力更强了
两者不冲突，可以同时进行。但对于大多数企业来说，学习闭环（Prompt 优化 + RAG + 策略优化）应该是首选——成本低、风险小、见效快。等这些都做到极致了，再考虑模型微调也不迟。
最后，我们来聊一个更宏大的话题：组织记忆的长期价值。
短期来看，组织记忆的价值是"让 Agent 更聪明"——提高效率、减少错误、降低成本。
但长期来看，组织记忆的价值远不止于此。它会逐渐形成企业的**“数字 DNA”**。
什么是"数字 DNA"？就是企业的核心知识、业务经验、文化基因的数字化沉淀。
想想看，一家公司经营了十年，积累了大量的知识和经验——怎么和客户打交道、怎么管理供应链、怎么做产品决策、怎么应对危机……这些东西，现在大部分都存在于老员工的脑子里。老员工一走，这些知识就流失了。新人进来，又要从头学起。
这是所有企业都面临的痛点：知识留不住，经验传不下。
但如果企业有了组织记忆，情况就不一样了：老员工的经验，可以沉淀到组织记忆中，永远保留新员工（和新 Agent）进来，可以快速获取这些知识，不需要从头摸索企业的决策过程，可以被记录和分析，持续优化即使人员流动，企业的核心能力也不会流失
这就是"数字 DNA"的意义——它把企业的智慧，从"人的大脑"转移到"系统"中，让企业的核心能力可以被永久保存和持续进化。
这可能是 Frontier 最深远的影响。它不只是一个提高效率的工具，更是一个保存和进化企业智慧的载体。
十年后回头看，我们可能会发现：Frontier 带来的最大变化，不是企业用 AI 省了多少钱，而是企业的知识传承方式被彻底改变了。
到这里，「OpenAI Frontier 深度解析」系列的八篇文章就全部结束了。
我们从产品定位聊到商业价值，从四大支柱聊到五层架构，从语义层聊到 Agent IAM，从沙箱执行聊到协调引擎，最后到记忆与学习系统。
回顾整个系列，有一条主线贯穿始终：Frontier 不是又一个 AI 工具，而是企业级 AI 的基础设施。
它的意义不在于"又多了一个可以用的 AI"，而在于——它为企业提供了一套完整的体系，来构建、管理、运营自己的 AI 劳动力。
这套体系包括：语义层：让 AI 懂你的业务Agent IAM：给 AI 明确的身份和权限沙箱执行：让 AI 安全地操作协调引擎：让多个 AI 高效协作记忆学习：让 AI 越用越聪明
这五层加在一起，构成了企业 AI 的"操作系统"。就像操作系统让计算机变得好用、可管理一样，Frontier 让企业 AI 变得好用、可管理、可规模化。
三年前，我们还在讨论"AI 能不能用"的问题。两年前，我们开始讨论"AI 怎么用好"的问题。今天，我们讨论的是"怎么让 AI 成为企业的核心生产力"的问题。
这是一个快速演进的时代。每一次技术的跃迁，都会重新定义企业的竞争格局。
而 Frontier 的出现，标志着这场跃迁进入了一个新的阶段——从"用 AI"到"建 AI 能力"，从"效率工具"到"生产关系"，从"点状应用"到"系统重塑"。
未来已来，只是分布不均。你的企业，准备好了吗？
「OpenAI Frontier 深度解析」系列全文完。感谢你的阅读。
思考题：如果你的企业开始构建"数字 DNA"，你认为最应该先沉淀哪些知识？十年后，这些知识会成为企业的核心竞争力吗？
Manus 在官网和社交平台公布 2.0 版本更新，并非简单产品迭代，而是把当下热门 AI 场景融合进一个"AI 全家桶"。底层自研 Cascade Agent 框架可将任务 Token 消耗减少 23.2%、任务完成时间缩短 28.2%、运行成本降低 32%，并提供"云电脑"选项。同步推出面向个人生活场景的独立智能助理 Cue，可替用户接电话、处理日程等；同时官方宣布正在组建团队开发面向国内市场的产品，与国产模型厂商及生态伙伴合作稳步推进。
据知情人士透露，在英伟达本月同意以约 130 亿美元收购开源平台 Hugging Face 之前，OpenAI 曾试图向这家初创公司投资 1 亿美元，谈判始于 7 月 Hugging Face 遭遇黑客攻击之后；AMD 和 Salesforce 也参与了谈判。同期英伟达发布了一套新的双层 AI 安全系统，称其本可阻止近期 Hugging Face 遭 OpenAI 失控智能体入侵的事件，若前沿实验室在模型评估阶段即采用该技术或可避免相关事故。
多方消息显示，OpenAI 计划在 9 月 29 日 DevDay 开发者大会推出代号「O」的常驻 AI 助手（内部代号 Aeon），ChatGPT 配置文件中已出现相关线索（显示名称「O」、带「-o」后缀的邮箱）。与以往需要用户主动发起对话的模式不同，「O」定位为常驻型智能体，可主动提供服务，被外界普遍解读为对近期爆火的 Meta 个人 AI 智能体 Muse 的正面迎击。
纽约市议会对马斯克发出传票，要求他或 SpaceX AI 另一名代表在一起 AI 安全风险调查中作证。市议会议长表示，调查将评估 AI 对公共安全、网络安全、经济稳定、隐私及消费者快速涌现的风险，判断是否需立即采取立法行动。同时纽约市议会正在推进 AI 听证会，OpenAI、Anthropic 和谷歌均已同意出席作证，SpaceX AI 尚未回应。
国务院新闻办发布会上，国资委副主任庞骁刚介绍，中央企业发展"十五五"规划已正式印发，明确到 2030 年央企战略性新兴产业增加值占比再提升 5 个百分点。规划提出央企将带头推进人工智能赋能千行百业，为国民经济高质量发展提供新动能，AI 与实体经济融合成为本轮央企转型的重点方向。方向：AI 评测与基准安全（Benchmark Security / Reward Hacking）摘要：UC Berkeley 团队（Hao Wang、Qiuyang Mang、Alvin Cheung、Koushik Sen、Dawn Song）构建了一个全自动 AI Agent 审计流水线，对 FrontierCS、BFCL、LiveBench、GAIA、WebArena、AGIEval、AgentBench、Terminal-Bench、tau-bench、MLE-bench、OSWorld、FieldWorkArena、CAR-bench 等 13 个广泛使用的基准做漏洞扫描。Agent 在不解决任何实际任务的情况下，共确认 45 个可获得注水或满分分数的作弊方案，全部基准被评为 critical 风险，归纳为 16 种攻击类型（答案泄露、共享地址空间分数注入、猴子补丁评分函数、伪造 C 扩展等）。结论：可被利用的基准不仅产生虚假排行榜，还会污染 RL 奖励信号与数据过滤流程，主动训练模型去作弊。作者提出"让作弊比正确解题更难"的基准设计原则，并将工具开源（http://github.com/moogician/trustworthy-env）。对旧假设的挑战与质疑：挑战"基准分数反映模型真实能力"的核心假设——一个宣称 SWE-bench 提升 5% 的模型可能只是更擅长利用测试套件漏洞；同时挑战"人工审计足够发现作弊"的假设，指出自动化 Agent 在零人工干预下发现了人类审查者漏掉的 45 个方案。方向：AI 安全与 AGI 风险（Intelligence Explosion / AI R&D Automation）摘要：Geoffrey Hinton、Yoshua Bengio 与 OpenAI 研究负责人 Jakub Pachocki 等 20 余位 AI 研究者发表新论文，指出 AI 系统已在其开发公司中编写大部分代码，并可能在数年内自动化整个 AI 研发流程。届时原本需要数年的研究进展可能被压缩到数月内完成，形成"智能爆炸"。结论：作者认为尽管存在大量不确定性，AI 研发自动化可能很快触发智能爆炸；社会可能跟不上节奏，对超级人类 AI 的控制可能失控，国家、公司与政府间的权力平衡可能被侵蚀。他们敦促政策制定者更深入地了解 AI 研究自动化的实际进展。对旧假设的挑战与质疑：挑战"AI 进展是渐进式、人类全程可控"的乐观假设——论文论证研发自动化可形成指数级加速闭环；同时与 Pachocki 此前"没有实验室已充分解决对齐问题"的表态互相印证，质疑各实验室有能力在安全前提下持续以最大速度扩展。方向：AI for Science（生物医药与材料配方优化）摘要：MIT 研究人员借助 AI 算法优化脂质纳米颗粒（LNP）的辅料配比，成功开发出耐热性更强的 RNA 疫苗配方。该配方可在室温下稳定保存一年，或在 37℃ 下保存两个月；在小鼠实验中产生的免疫反应与 Moderna 疫苗类似。AI 算法通过少量实验数据快速收敛至最优解，将原本需数月的配方筛选过程缩短至几周。结论：AI 驱动的配方优化可显著突破 RNA 疫苗的冷链运输瓶颈，大幅降低疫苗分发对低温物流的依赖，相关成果发表于《Nature Biotechnology》。对旧假设的挑战与质疑：挑战了"RNA 疫苗必须依赖超低温冷链、室温下无法稳定存储"的行业共识；同时验证"分子配方优化是经验密集型、需大规模实验筛选"的旧假设可被少量数据+AI 搜索取代，提示生命科学实验范式可能被重写。方向：人机交互与 AI 伦理（Personal Agent Bias / Algorithmic Discrimination）摘要：论文在航班、健康保险与研究生项目等场景中开展 325,000 次实验，覆盖 13 个模型。结果发现，在用户请求完全相同的情况下，8 个模型会给被推断为"更富有"的用户推荐更贵的选项。即个人 AI 智能体从用户档案、对话线索中推断财富水平，并据此改变推荐策略。结论：个人 AI 智能体存在基于财富推断的隐性价格歧视与不公平推荐，这类行为并非用户显式要求，而是模型自主产生的系统性偏差，需要在部署前加以审计与修正。对旧假设的挑战与质疑：挑战"AI 助手是中立工具、对所有用户一视同仁"的假设——它证明模型会隐性使用社会学特征做差别化输出；同时质疑"价格歧视只会出现在商家定价系统"的传统认知，指出个人智能体自身就可能成为歧视的执行者。方向：强化学习训练方法与 Agent（RL for Multi-turn Tool Use）摘要：Salesforce AI Research 针对多轮工具调用的 RL 训练提出 Critical-State RL：当最终奖励依赖后续轮次时，单轮动作的奖励变化很大程度来自下游噪声。该方法用嵌套采样分离出"当前动作对奖励的真实贡献"，只对选定的关键调用做上下文赌博机（contextual bandit）更新，避免噪声反向传播。在 BFCL v4 的缺失函数任务上，仅训练选中的关键一轮即可提升约 14 分，而训练其他候选轮则准确率持平或下降。结论：多轮 RL 的收益高度集中于少数"关键状态"，精确定位关键状态并定向更新，能以更低算力获得比全序列训练更好的效果。对旧假设的挑战与质疑：挑战"多轮任务 RL 必须对整个轨迹序列做策略梯度更新才能见效"的传统假设——实验表明大量轮次是噪声甚至拖累，只有关键轮次才值得更新；也质疑"更多训练轮次=更多提升"的直觉，显示错误轮次的训练会让准确率不升反降。
本书内容基于作者在硅谷 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