AI架构师重构智能体系统：确定性代码接管路由以终结模型失控

别再做玩具Demo了！10分钟带你从0到1搭建工业级AI Agent — AI大模型-阿水

AI大模型-阿水

大模型主导全流程必然导致生产系统崩溃，工业级智能体必须用传统硬编码锁死路由控制与安全红线，仅将模型保留在局部的语义处理节点。

AI-assisted summary of 别再做玩具Demo了！10分钟带你从0到1搭建工业级AI Agent — original source. Check the original for full context.

Source published:

Key ideas

  • 工业级 AI Agent 架构的核心在于边界划分：必须用确定性代码硬编码工作流控制路由与重试，仅将大模型限制在处理局部不确定性的语义理解节点上。 (3:07)
  • 针对 AI 辅助编程，项目根目录应设立 agents.md 明确目录结构、代码修改禁区与依赖规则，避免大模型协同开发时破坏底层逻辑。 (1:52)
  • 工具（Tools）应遵循单一职责原则并能脱离 Agent 独立单测，而高鲁棒性技能（Skills）则是将经过验证的标准作业程序（SOP）固化为核心业务资产。 (5:40)
  • Agent 评估不能仅看代码是否报错，必须通过包含真实业务题目的固定评测集（Benchmark），从事实准确率、工具准确率、Token 成本和响应耗时量化衡量。 (9:05)

Detailed notes

## Background 该内容由 Bilibili UP 主“AI大模型-阿水”于 2026 年 10 月 7 日发布。视频简介提供了包含 Agent 学习资料、大模型学习路线、实战案例集与电子书等配套资源的专栏链接，旨在帮助开发者解答实践难题并获取系统化材料。

## TL;DR 视频深入剖析了玩具级 Demo 与工业级 AI Agent 之间的工程鸿沟，强调在编码前必须明确业务边界与安全红线（Human-in-the-Loop）。核心架构上，主张用确定性的代码工作流来管控路由与重试，仅将不确定性决策交由智能体处理，并对输出字段进行严格格式化约束。此外，讲者系统性拆解了工具与技能的解耦、上下文与长期记忆的治理边界、提示词的模块化版本控制，以及基于固定评测集的量化评估与全链路可观测性，提供了一套从研发到上线的完整工业级工程闭环指南。

## Atmosphere & style 视频整体呈现出极强的一线实战工程风格，语调清醒、干练且直击要害，毫无空泛的技术炒作或盲目乐观。讲者如同经验老道的资深架构师在进行内部复盘，以一针见血的言辞破除“无脑套用向量库”或“凭感觉调 Prompt”的业余误区。整场分享节奏紧凑严密，层层推进架构原则，给观众带来一种褪去浮躁、重回软件工程严谨本质的踏实感与掌控感。

## Bulletin - [03:07](https://www.bilibili.com/video/BV1nyHC6mEBr?t=187s) 工业级 AI Agent 架构的核心在于边界划分：必须用确定性代码硬编码工作流控制路由与重试，仅将大模型限制在处理局部不确定性的语义理解节点上。 - [01:52](https://www.bilibili.com/video/BV1nyHC6mEBr?t=112s) 针对 AI 辅助编程，项目根目录应设立 agents.md 明确目录结构、代码修改禁区与依赖规则，避免大模型协同开发时破坏底层逻辑。 - [05:40](https://www.bilibili.com/video/BV1nyHC6mEBr?t=340s) 工具（Tools）应遵循单一职责原则并能脱离 Agent 独立单测，而高鲁棒性技能（Skills）则是将经过验证的标准作业程序（SOP）固化为核心业务资产。 - [09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) Agent 评估不能仅看代码是否报错，必须通过包含真实业务题目的固定评测集（Benchmark），从事实准确率、工具准确率、Token 成本和响应耗时量化衡量。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1nyHC6mEBr?t=0s) 打造生产级 Agent 必须杜绝‘全知全能超级助手’的幻想，开发前需明确核心目标、输入数据、交付结果、自主边界与成功指标五大要素。 - [00:00](https://www.bilibili.com/video/BV1nyHC6mEBr?t=0s) 在涉及对外发布内容、删除文件或高昂计费外部调用等高风险节点，系统必须设置安全红线并引入人工确认（Human-in-the-Loop）。 - [01:52](https://www.bilibili.com/video/BV1nyHC6mEBr?t=112s) 项目应当在根目录维护 agents.md 规范文件，向 AI 编程助手明确代码禁区、测试要求和依赖规则，以减少返工成本。 - [01:52](https://www.bilibili.com/video/BV1nyHC6mEBr?t=112s) API Key 严禁硬编码至版本控制仓库，应通过本地配置文件与 .env.example 模板进行环境变量隔离。 - [03:07](https://www.bilibili.com/video/BV1nyHC6mEBr?t=187s) 工作流（Workflow）负责确定性的时序流转与兜底重试，智能体（Agent）仅负责不确定性的语义理解与局部动态决策，不可本末倒置。 - [04:22](https://www.bilibili.com/video/BV1nyHC6mEBr?t=262s) 智能体间协作依赖严格固化的结构化输出（如核心结论、关键事实等固定字段），以保障流水线下游解析逻辑的稳定性。 - [05:40](https://www.bilibili.com/video/BV1nyHC6mEBr?t=340s) 工具（Tools）负责解决‘能不能干’并遵循单一职责，而技能（Skills）负责解决‘怎么干最靠谱’的 SOP 业务方法论。 - [07:22](https://www.bilibili.com/video/BV1nyHC6mEBr?t=442s) 严格区分单次任务即抛的上下文（Context）与跨周期具有指导价值的记忆（Memory），避免盲目迷信向量数据库导致记忆污染。 - [08:26](https://www.bilibili.com/video/BV1nyHC6mEBr?t=506s) 提示词应按系统角色、任务、硬性约束、示例和输出格式分层解耦，并作为核心代码资产全面接入 Git 版本控制与 Code Review。 - [09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) 单元测试代码全绿不等于业务交付合格，系统必须引入独立 Benchmark 评测集量化评估大模型幻觉与任务质量。 - [09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) 线上翻车的 Bad Case 在脱敏后应及时转化为基准评测集中的新考题，实现系统的量化回归与持续迭代进化。 - [10:04](https://www.bilibili.com/video/BV1nyHC6mEBr?t=604s) 生产环境需建立完备的全链路可观测性（Observability），记录决策推理链与外部响应，避免出 Bug 时盲目修改提示词。 - [10:04](https://www.bilibili.com/video/BV1nyHC6mEBr?t=604s) 工业级 Agent 必须坚持‘运行-追踪-评估-重构-再评估’的闭环迭代节奏，用严谨的工程化手段收敛 AI 的不确定性。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1nyHC6mEBr?t=0s) 告别玩具 Demo：从商业落地的视角审视 AI Agent

很多人误以为只要调用几个大模型的 API 接口、写过几段酷炫的提示词（Prompt），或者给模型挂载两个工具，就算是掌握了 AI Agent。然而，一旦接触真实的商业项目，开发者往往会立刻陷入迷茫：目录结构该如何组织？庞大的系统模块怎么切分？哪一部分应该用确定性的代码写死，哪一部分又该放权让模型自主决策？一个仅能在本地勉强跑通的玩具 Demo，与一个真正能在生产环境中养活业务的工业级项目之间，存在着巨大的工程鸿沟。

打造工业级 Agent，首要前提不是急着敲代码，而是停下来明确业务目标与任务边界。业内常见的一个误区是试图打造“全知全能的超级助手”——既能全网搜集资料、写爆款文案，又能顺手处理 Excel 表格。这类缺乏边界的项目“10 个里面有 9 个最后都会烂尾”，其核心原因在于任务边界过于模糊。在写下第一行代码前，必须在纸面上清晰界定五大核心要素：

- **核心目标**：系统到底替谁解决什么具体的业务痛点。 - **输入数据**：用户在什么场景下会提供怎样的数据格式与内容。 - **交付结果**：系统端到端最终输出的明确交付物是什么。 - **自主边界**：流程中哪些节点允许模型自主做决定，哪些环节必须受到严格限制。 - **成功指标**：达到何种量化标准或业务指标才算项目成功。

以一个“自媒体内容助手”为例：用户输入一个热门话题，系统负责全网检索、对官方数据和新闻报道进行交叉比对、提炼核心观点，并最终输出一份完整的短视频脚本。在这个流水线中，搜索资料和整理大纲允许模型自由发挥；但一旦涉及**对外公开发布内容**、**删除本地文件**或**调用按次/按时计费的高昂外部接口**，系统就必须设置不可逾越的红线——流程立刻暂停，强制等待人工确认（Human-in-the-Loop）。如果前期目标模糊，后期工具便会越加越多、记忆越理越乱，开发者很快就会彻底丧失对代码逻辑的把控。

```mermaid flowchart TD accTitle: 自媒体内容助手任务流与安全红线 accDescr: 展示自媒体内容助手的处理阶段，以及在敏感操作节点触发人工确认的控制流。

subgraph Autonomous["自主发挥环节 (AI 决策)"] A["输入热门话题"] --> B["全网搜索信息"] B --> C["官方/新闻数据交叉比对"] C --> D["提炼核心观点 & 拟定大纲"] end

subgraph Guardrail["安全红线节点 (强制等待人工确认)"] D --> E{"是否涉及敏感操作？\n(对外发布 / 删文件 / 高昂计费)"} E -- "是" --> F["流程挂起：等待人工确认 (Human-in-the-Loop)"] E -- "否" --> G["生成最终短视频脚本"] F --> G end ```

---

[01:52](https://www.bilibili.com/video/BV1nyHC6mEBr?t=112s) 项目基建与规矩：编写给 AI 看的 `agents.md`

确定目标后，系统需要建立底层的开发规范。除了标准的代码仓库搭建与环境变量隔离之外，在广泛使用 Cursor、Claude 等 AI 编程助手的今天，开发者必须建立一个关键习惯：在项目根目录下创建一个专供 AI 阅读的规范文件（如 `agents.md`）。这份文件相当于给 AI 辅助编程制定的“项目家规”。

在 `agents.md` 中，必须明确约定： - **目录组织结构**：核心业务逻辑存放在哪个文件夹。 - **代码修改禁区**：哪些底层核心框架代码绝对禁止 AI 擅自改动。 - **测试门禁**：增加新功能后，必须跑通哪些自动化测试用例。 - **依赖安全**：严禁 AI 擅自引入未经许可的第三方依赖库。 - **提交规范**：提交代码（Commit）前必须完成的各项静态检查。

把这些规矩提前锁死，后续让 AI 辅助重构代码或排查 Bug 时，它就无需盲目猜测开发者的代码习惯，从而避免大量的返工与逻辑破坏。此外，API Key 的管理必须遵守安全基线，绝不能硬编码（Hardcode）在代码仓库中；真实密钥应存储在本地未纳入版本控制的隐藏配置文件中，代码库中仅提供一份示例文件（如 `.env.example`）以供团队协作对齐。

---

[03:07](https://www.bilibili.com/video/BV1nyHC6mEBr?t=187s) 架构拆分：工作流管确定性，智能体管不确定性

一个具备长久维护性的 Agent 项目，其核心模块通常划分为：**智能体（Agents）**、**工具（Tools）**、**技能（Skills）**、**工作流（Workflows）**、**提示词（Prompts）**、**上下文与记忆（Context & Memory）** 以及 **测试与评估模块（Evaluation）**。其中，初学者最容易混淆的概念就是“工作流”与“智能体”。

| 概念 | 核心职责 | 特性 | 实现方式 | |:--- |:--- |:--- |:--- | | **工作流 (Workflow)** | 掌控任务执行的先后次序、路由控制与兜底逻辑 | **确定性** | 传统代码硬编码写死 (Python, TypeScript 等) | | **智能体 (Agent)** | 在缺乏明确规则的节点上进行语义理解、动态决策与工具调用 | **不确定性** | 大语言模型 (LLM) 动态推理 |

将两者混为一谈，试图打造一个承担全流程控制的超级 Agent，是系统走向脆弱与不可维护的根源。在内容助手项目中，调研 Agent 负责查资料，写稿 Agent 负责产出脚本，二者各司其职。如果调研 Agent 收集的信息不足，是更换关键词重试还是跳过？如果生成的脚本连续两次不达标，是退回重新检索还是仅修改文案？这类**路由控制、重试策略和兜底逻辑，必须用确定性的代码写死，绝不能交给大模型动态决定**。

如果把路由大权交给模型，前期可能看似聪明，但业务逻辑一旦复杂，模型在中间某一步走偏，排查成本将极其高昂。只有让代码负责骨架的确定性流转，将模型限制在需要语义理解的局部节点上，未来升级模型权重或替换 Agent 时，系统的整体架构才能坚如磐石。

```mermaid flowchart LR accTitle: 工作流与智能体的协同架构 accDescr: 展示确定性的代码工作流如何包裹并调度不确定性的模型节点与兜底逻辑。

subgraph DeterministicWF["确定性工作流 (代码控制流)"] Start["任务启动"] --> Step1["调度：调研节点"] Step1 --> Check{"数据是否充足？\n(代码规则校验)"} Check -- "不足 (重试 < 2次)" --> Retry["代码自动更换关键词重试"] Retry --> Step1 Check -- "充足" --> Step2["调度：写稿节点"] Step2 --> Eval{"质量评估\n(规则/分数检查)"} Eval -- "不及格" --> Fallback["代码路由：退回打回重做"] Fallback --> Step1 Eval -- "及格" --> Finish["交付结果"] end

subgraph DynamicAgent["不确定性节点 (LLM 决策)"] Step1 -.-> A1["调研 Agent\n(语义提取 & 资料比对)"] Step2 -.-> A2["写稿 Agent\n(风格拟定 & 文案生成)"] end ```

---

[04:22](https://www.bilibili.com/video/BV1nyHC6mEBr?t=262s) 规范智能体：严格固化输出数据结构

定义一个工业级 Agent，有五大核心要素缺一不可：**角色设定**、**核心目标**、**操作指令**、**可用工具**，以及**输出的数据结构**。

以调研 Agent 为例： - **角色设定**：资深行业研究员。 - **核心目标**：搜集并提取真实、可靠的行业背景资料。 - **操作指令**：优先采信官方渠道发布的数据；发现信息冲突时必须单独标出；拿不准的推测绝对不得当作既定事实陈述。 - **可用工具**：挂载网页搜索工具与正文抓取工具。 - **输出结构**：必须强制使用固定字段的结构化输出（JSON 或固定格式），包含以下五个标准字段： 1. `核心结论` 2. `关键事实` 3. `信息来源` 4. `争议点` 5. `待确认项`

在流水线架构中，输出数据结构的标准至关重要。下游的写稿 Agent 依赖标准字段来推进任务。如果调研 Agent 的输出忽冷忽热——今天给一段自然语言总结，明天丢几个裸链接，后天把主观臆断与客观事实混在一起——下游的解析逻辑必然频繁崩溃。许多工业级 Agent 系统之所以稳定，靠的往往不是换用了多么昂贵的前沿模型，而是各个 Agent 之间的**职责边界极其清晰、数据输入输出规范极其严格**。

---

[05:40](https://www.bilibili.com/video/BV1nyHC6mEBr?t=340s) 工具与技能的解耦：单一职责与 SOP 沉淀

在 Agent 的能力支撑层中，必须严格区分“工具（Tools）”与“技能（Skills）”的概念，并在工具设计上贯彻“单一职责原则”。

**工具设计原则：一个工具只干一件极度明确的事**。 搜索就专注于纯文本检索，抓取就专注于纯页面解析，切忌构建“大包大揽”的复合型臃肿工具。大模型是在推理阶段阅读工具的描述文本（Function Description）来决定是否调用该工具的；工具功能越臃肿复杂，描述文档就越难精准表达，模型误判与调用错误的概率就会呈指数级上升。此外，工具必须保证输入输出的严格结构化（如搜索工具入参为关键词字符串，输出为包含标题、摘要、URL 的结构化列表），且必须能**脱离 Agent 进行独立的单元测试与运行**。一旦整个系统出现故障，开发者可以立即断定是外部工具接口失效，还是 Agent 自身推理抽风选错了工具。

**工具 vs 技能的核心差异**： - **工具（Tools）**：解决的是“**我能不能干**”的基础能力问题。例如：抓取网页是一个工具，保存文件到本地也是一个工具，它们如同零件。 - **技能（Skills）**：解决的是“**怎么干才最靠谱**”的方法论问题。例如：“如何深度调研一款刚发布的 AI 产品”是一套技能。该技能将一套经过验证的 SOP（标准作业程序）固化为逻辑链条：第一步查阅官网核心声明，第二步调取技术开发文档，第三步检索社区开发者的真实反馈，第四步交叉核对矛盾点并生成评估报告。

一个工业级项目长期迭代所积累的核心数字资产，绝非网上随处可见的工具调用代码，而是这些经过大量实战反复打磨出来的“高鲁棒性技能包”。面对全新业务，系统只需直接挂载该技能包即可运转，无需重新试错。

---

[07:22](https://www.bilibili.com/video/BV1nyHC6mEBr?t=442s) 上下文与记忆治理：警惕对向量数据库的盲目迷信

许多开发者在构建 Agent 时存在技术执念，认为不挂载向量数据库（Vector DB）、不做 RAG（检索增强生成）就不够高端。然而在工程实践中，必须将“上下文”与“记忆”严格划清界限：

- **上下文（Context）**：仅为**当前单次任务**服务的数据。包括用户当前刚输入的指令、本轮爬虫刚抓取的页面内容、当前工作流流转的中间状态。这部分数据在当前任务执行完毕后即可丢弃。 - **记忆（Memory）**：跨越多个任务周期、对未来具有**长期指导价值**的核心资产。例如：用户长期厌恶的文风类型、特定客户对于产出成果的固定排版规则、长期稳定的业务偏好。这部分信息才具备持久化进入记忆库的资格。

像单次执行产生的临时报错日志、时效性极强的网页缓存，若无脑存入长期记忆库，不仅挤占存储，更会导致模型记忆混乱。一旦模型记住了错误的经验，后续想要纠正将极其痛苦。在项目初期，采用本地简单的文本文件或轻量级关系型数据库进行持久化完全足够；只有当数据规模与跨任务检索确实产生性能瓶颈时，再引入向量数据库做语义检索也为时不晚。

---

[08:26](https://www.bilibili.com/video/BV1nyHC6mEBr?t=506s) 提示词工程化：分层解耦与 Git 版本控制

在生产级软件工程中，严禁将所有背景信息、业务规则与格式约束混杂在一篇数千字的长篇提示词中。专业的做法是对提示词进行**模块化分层解耦**，通常拆解为四个独立维度： 1. **系统角色（Role）** 2. **当前任务（Task）** 3. **硬性约束（Constraints）** 4. **优秀示例（Few-Shot Examples）** 5. **输出格式（Output Format）**

模块化拆解的价值在于精准调试。如果线上运行发现模型偶尔胡编乱造，开发者只需针对性修改“硬性约束”模块的描述，而无需推翻整套 Prompt。更关键的是，所有拆解后的提示词必须全面接入 **Git 进行版本控制**。在工程化视角下，Prompt 本身就是 Agent 程序逻辑的核心代码组件。“能不能像管理源码一样对提示词进行版本管理与审查（Code Review），正是业余 Demo 与专业工程团队的最大分水岭。”

---

[09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) 测试与评估机制：告别“感觉变聪明了”的玄学优化

传统软件测试（单元测试、接口连通性测试）固然重要，但 Agent 项目有一个极为致命的工程陷阱：“**代码一路绿灯，不代表任务干得漂亮**”。 例如：调研 Agent 顺利执行、没报任何语法错误或网络异常、单元测试全部通过，最后洋洋洒洒生成了 3000 字报告；但仔细人工核对却发现，里面引用的核心数据是三年前的陈旧信息，甚至出现了严重的大模型幻觉（Hallucination）。从程序员的视角看代码完全跑通了，但从业务视角看交付物彻底砸了。

因此，工业级系统必须引入独立的**评估机制（Evaluation）**： - **构建固定评测集**：沉淀几十甚至上百道覆盖各类边界条件的真实业务考题，将其固定为基准评测集（Benchmark）。 - **回归评估指标**：每次更换底层基础大模型、调整 Prompt 模块、或是新增技能流程时，系统自动在评测集上完整重跑，并从**事实准确率**、**工具调用准确率**、**Token 消耗成本**以及**端到端响应耗时**四个维度打出综合得分。 - **动态进化**：评估考题集本身也需要纳入版本管理。线上出现任何翻车 Bad Case 时，在做完数据脱敏后立即转化为新的考题沉淀进题库，倒逼系统在真实的错误反馈中持续迭代进化。

只有当新方案的综合评分在量化指标上显著超越旧方案时，才能确认本次优化有效；在严谨的软件工程面前，仅凭“我感觉它好像变聪明了”的感性认知是毫无说服力的。

---

[10:04](https://www.bilibili.com/video/BV1nyHC6mEBr?t=604s) 生产可观测性：在不确定性中建立掌控感

当 Agent 系统最终打包部署上线，工程挑战才刚刚开始。与传统软件输出具有确定性不同，由于底层模型的随机采样机制或网络微小波动，同一段输入可能得到不同的执行轨迹。因此，**可观测性（Observability）**是系统持续迭代的眼睛。

生产环境的后台链路监控系统必须能够实时清晰记录： - 用户的原始请求与意图解析结果。 - 当前工作流所处的具体流转步骤与状态。 - Agent 在该决策瞬间，**为什么**决定调用特定工具（决策推理链）。 - 外部工具返回的原始响应数据与响应耗时。 - 全流程消耗的 Prompt Tokens、Completion Tokens 及实际花费金额。

完备的监控与日志系统能直接斩断“一出 Bug 就瞎改提示词、越改系统越乱”的死循环。例如，当有业务方投诉返回结果有误时，调出全链路追踪（Trace）发现：Agent 的推理逻辑与工具选用完全无误，仅仅是因为调用外部搜索工具时恰好检索到了一个过期的第三方页面。此时优化方向明确是更新数据源过滤规则，而不是盲目调整提示词。

工业级 Agent 的开发节奏应当遵循闭环：“**运行（Run） $\rightarrow$ 记录（Trace） $\rightarrow$ 评估（Eval） $\rightarrow$ 修改（Refactor） $\rightarrow$ 再评估（Re-Eval）**”。动手前定边界，编码前立家规；用工作流守住确定性，让智能体专职不确定性；工具管动作，技能沉 SOP；上下文管眼前，记忆管资产；提示词版本化，评测集指标化，全链路透明化。唯有借助这一整套扎实的工程化手段，天生具备不确定性的 AI 才能最终生长为一个高稳定性、可扩展、敢于向商业客户正式交付的工业级产品。

## Notable quotes > [00:00](https://www.bilibili.com/video/BV1nyHC6mEBr?t=0s) 10 个里面有 9 个最后都会烂尾

> [03:07](https://www.bilibili.com/video/BV1nyHC6mEBr?t=187s) 工作流管确定性，智能体管不确定性

> [03:07](https://www.bilibili.com/video/BV1nyHC6mEBr?t=187s) 路由控制、重试策略和兜底逻辑，必须用确定性的代码写死，绝不能交给大模型动态决定

> [05:40](https://www.bilibili.com/video/BV1nyHC6mEBr?t=340s) 一个工具只干一件极度明确的事

> [05:40](https://www.bilibili.com/video/BV1nyHC6mEBr?t=340s) 工具解决的是‘我能不能干’的基础能力问题，技能解决的是‘怎么干才最靠谱’的方法论问题

> [08:26](https://www.bilibili.com/video/BV1nyHC6mEBr?t=506s) 能不能像管理源码一样对提示词进行版本管理与审查，正是业余 Demo 与专业工程团队的最大分水岭

> [09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) 代码一路绿灯，不代表任务干得漂亮

> [09:05](https://www.bilibili.com/video/BV1nyHC6mEBr?t=545s) 我感觉它好像变聪明了

> [10:04](https://www.bilibili.com/video/BV1nyHC6mEBr?t=604s) 运行 $\rightarrow$ 记录 $\rightarrow$ 评估 $\rightarrow$ 修改 $\rightarrow$ 再评估

## Mentioned Cursor, Claude, Git, Python, TypeScript, Excel

## Video description 视频Agent学习籽料、大模型学习路线、、实战案例集、电子书+问题解答👉https://www.bilibili.com/read/cv52978347/?spm_id_from=333.1387.0.0&amp;jump_opus=1自取哦

[Source](https://www.bilibili.com/video/BV1nyHC6mEBr)

中文简报

AI架构师重构智能体系统：确定性代码接管路由以终结模型失控 大模型主导全流程必然导致生产系统崩溃，工业级智能体必须用传统硬编码锁死路由控制与安全红线，仅将模型保留在局部的语义处理节点。 视频深入剖析了玩具级 Demo 与工业级 AI Agent 之间的工程鸿沟，强调在编码前必须明确业务边界与安全红线（Human-in-the-Loop）。核心架构上，主张用确定性的代码工作流来管控路由与重试，仅将不确定性决策交由智能体处理，并对输出字段进行严格格式化约束。此外，讲者系统性拆解了工具与技能的解耦、上下文与长期记忆的治理边界、提示词的模块化版本控制，以及基于固定评测集的量化评估与全链路可观测性，提供了一套从研发到上线的完整工业级工程闭环指南。 工业级 AI Agent 架构的核心在于边界划分：必须用确定性代码硬编码工作流控制路由与重试，仅将大模型限制在处理局部不确定性的语义理解节点上。 (3:07) 针对 AI 辅助编程，项目根目录应设立 agents.md 明确目录结构、代码修改禁区与依赖规则，避免大模型协同开发时破坏底层逻辑。 (1:52) 工具（Tools）应遵循单一职责原则并能脱离 Agent 独立单测，而高鲁棒性技能（Skills）则是将经过验证的标准作业程序（SOP）固化为核心业务资产。 (5:40) Agent 评估不能仅看代码是否报错，必须通过包含真实业务题目的固定评测集（Benchmark），从事实准确率、工具准确率、Token 成本和响应耗时量化衡量。 (9:05)

Reading summary

《AI大模型-阿水》指出，从玩具 Demo 跨越到工业级 AI Agent 的核心，在于用确定性的软件工程手段约束大语言模型的不确定性，而非盲目堆砌工具或追求全知全能的超级助手。 划定业务边界与安全红线 (0:00) 业内常见误区是试图打造能全网搜集、撰写文案兼处理表格的“全能助手”，但此类缺乏边界的项目大多走向烂尾。在编码前必须明确核心目标、输入数据、交付结果、自主边界与成功指标五大要素。在流程设计中，资料检索和大纲拟定等环节可放权给模型自主决策，但若涉及对外公开发布内容、删除本地文件或调用高额计费接口等敏感操作，系统必须设置阻断红线，强制进入人工确认（Human-in-the-Loop）流程。 工作流保确定性，智能体管不确定性 (3:07) 系统架构治理的核心是理清工作流（Workflow）与智能体（Agent）的分工。工作流掌控执行顺序、路由控制、重试与兜底逻辑，具有确定性，必须使用传统代码硬编码写死；智能体仅在缺乏明确规则的节点上负责语义理解与动态推理。将路由大权交给模型会导致系统在复杂业务下极易走偏且排查困难。同时，智能体必须严格固化输入与输出格式，例如调研 Agent 需稳定输出包含“核心结论、关键事实、信息来源、争议点、待确认项”的结构化字段，以防下游解析崩溃。 解耦工具与技能，规范上下文与记忆治理 (5:40) 在能力层，工具必须遵循单一职责原则，只干一件明确的事（如纯文本搜索或纯网页解析），保持输入输出结构化并能脱离 Agent 独立进行单元测试，以防模型误判；技能则是将经过验证的方法论沉淀为标准作业程序（SOP）。在数据存储上，必须区分仅服务于单次任务的临时上下文与跨周期沉淀的长期记忆，避免无脑引入向量数据库。单次运行的报错日志或时效性缓存存入长期记忆会导致模型认知混乱，初期使用轻量关系型数据库或本地文本即可满足需求。 提示词工程化与指标量化评测 (8:26) 生产级系统应将提示词拆解为系统角色、当前任务、硬性约束、优秀示例及输出格式等独立模块，便于精准调试，并全面纳入 Git 版本控制。针对传统软件测试“代码全绿但交付物质量糟糕（如陈旧数据或幻觉）”的困境，工业级开发必须建立包含业务真实考题的基准评测集。每次更换底模、改动提示词或调整技能后，必须在评测集上回归测试，并依据事实准确率、工具调用准确率、Token 消耗成本和响应耗时综合打分，线上翻车的 Bad Case 也需脱敏沉淀进题库，杜绝凭感性评估效果。 生产全链路追踪闭环 (10:04) 由于大语言模型存在采样随机性，系统上线后必须依赖完备的可观测性进行监控。后台需实时记录用户的原始意图、工作流状态、Agent 选择工具的推理链、外部接口原始响应以及 Token 花费与耗时。全链路追踪有助于排查故障根因，避免线上出错时盲目调整提示词，从而形成“运行-记录-评估-修改-再评估”的稳定迭代闭环。 工业级 AI Agent 的本质并非依赖昂贵模型，而是通过前期立规、代码硬化路由、工具与技能解耦、评测指标化以及全链路监控等工程化规范，使系统在面对不确定性时保持鲁棒与可交付。

Source quotes

[0:00] 10 个里面有 9 个最后都会烂尾 [3:07] 工作流管确定性，智能体管不确定性 [3:07] 路由控制、重试策略和兜底逻辑，必须用确定性的代码写死，绝不能交给大模型动态决定 [5:40] 一个工具只干一件极度明确的事 [5:40] 工具解决的是‘我能不能干’的基础能力问题，技能解决的是‘怎么干才最靠谱’的方法论问题 [8:26] 能不能像管理源码一样对提示词进行版本管理与审查，正是业余 Demo 与专业工程团队的最大分水岭 [9:05] 代码一路绿灯，不代表任务干得漂亮 [9:05] 我感觉它好像变聪明了 [10:04] 运行 $\rightarrow$ 记录 $\rightarrow$ 评估 $\rightarrow$ 修改 $\rightarrow$ 再评估

Original transcript

[0:00] 很多朋友以为自己会挑几个大母线的接口写过几段炫酷的提示词甚至给模型挂上过两个工具就算掌握AIAGENT了但只要你一解锁真正的商业项目立马就会发懵文件夹到底该怎么建?庞大的模块怎么切分?哪一部该用代码写死流程,哪一部又该放权?让模型自己拿主意,今天咱们不搞虚的。我直接带你从零开始把一个真正能落地干活的agent项目完整盘一遍这不是那种随便接个API就玩似的玩具教程我整理了一番大模型和Agent系统学习路线只要是我粉丝留下666打包带走咱们完全按照真实开发团队的标准来从初期的需求定义,项目的底层规范,一路聊到架构设计,工具与技能的区分再到记忆管理,提示词的版本控制最后是测试评估和上线监控看完这些你就会彻底明白一个agent的项目从勉强跑得通到真正能养的活业务中间到底差了些什么咱们现在直接进入正题写代码之前大家先停下来思考一个问题你的这个agent到底是替谁解决什么具体的麻烦不少人刚结束agent上来就想造一个全知全难的超级助手尽能全网查资料用那些爆款文案还能顺手帮你做个一个sell表听起来特别厉害对吧但现实是这种没有边界的项目10个里面有9个最后都会烂尾原因很简单任务边界太模糊了所以在瞧下第一行代码前 你得先在纸上明确五件事你的核心目标是什么用户到底会输入什么样的数据系统最终要交付什么结果在整个流程里哪些缓解云悬崖的自己做决定以及这个项目做到什么指标才算成功我拿自己做过的一个自媒体内容助手来举例用户丢进了一个热门话题这个助手会先去全网搜索然后把官方数据、新闻报道做交叉比对筛选出靠谱的信息,接着提炼核心观点最后输出一份完整的短视频脚本大家注意这里面有一条绝对不能碰到红线搜索资料整理大纲,这些动作它可以自由发挥但是只要涉及到对外发布内容删除本地文件或者调用那些暗时收费的昂贵接口流程必须立刻停下来等人工确认为什么要定这么死?因为如果前期目标含糊后期你家的工具就会越来越多模型的记忆也会越来越乱过不了多久你自己都看不懂某段逻辑是干嘛用的所以先定义清楚任务,再去设计系统,这是铁律,想清楚了目标,接下来咱们得给项目立点规矩先代码仓库,配置环境变量,这些基础操作咱们就不多说了这里我重点分享一个很多开发者还没养成的好习惯如果你平时写代码会用到像Cursor或者Cloud,这类AI变成助手我强烈建议你在项目的根目录下建一个专门的说明文件比如叫agents.md这其实就是一份专门写给AI看的项目加规在这个文件里呢你要明明白白的告诉AI咱们的目录是怎么组织的核心逻辑放在哪个文件夹哪些底层文件是绝对不能修改的禁区增加新功能之后必须跑通哪些测试远不允许它自动安装地上方依赖提交代码前要做哪些检查把这些规矩提前定好以后你让AI帮你改bug或者加功能的时候它就不需要每次都去狭采你的代码习惯能帮你省下大量的反攻时间另外,APM密钥的管理必须重视绝对不能直接写在代码里真实的密钥放在本地的隐藏文件里同时给团队留一份示例文件让大家知道需要哪些配置先立好规矩,再让AI介入这个顺序千万不能反规矩定好了,咱们来聊聊最容易让人迷糊的目录架构一个准备长期跑下去的A进的项目通常会拆分出好几个核心模块智能体、工具、技能、工作流提示词上下文记忆 还有测试和评估模块这里面大家最容易搞混的就是工作流和智能体很多人觉得这俩是一回事其实完全不同大家想一想工作流管的是什么它管的是事前按什么顺序往下走这是确定性的而智能体管的是遇到没把握的情况该怎么做判断这是不确定性的这其实也是目前业内顶尖团队的共识工作流就是你提前写好的代码路径而智能体是在这个路径的某些节点上由大模型动态决定怎么用工具还是拿刚才的内容助手举例负责找资料的agent 负责写稿的agent 他们各司其职但是如果找资料的agent没收到足够的信息是继续换关键词收还是直接进入下一步如果写出来的稿子连续两次都不及格,是重新生成,还是打回去重新找资料?这些路由控制和兜底的逻辑绝对不能扔给一个所谓的超级agent让他自己去想前夕你可能觉得他挺聪明等业务逻辑复杂它还是走错了一步你根本查不出来原因最稳妥的做法是把确定性的流程用传统的代码写死只有真正需要临场发挥作语以判断的节点才交给大模型这样以后你想生机某个模型或者替换掉某个agent整个系统的股价依然是稳的把价格理顺了咱们才真正开始定义Agent的本身定一个agent有五样东西是权一不可的角色设定、核心目标、操作指令、可用工具以及输出的数据结构比如咱们那个负责调研的agent学士就是资深行业研究员目标是获取真实可靠的背景资料指令里要明确告诉他优先相信官方渠道遇到矛盾的信息要单独标出来 [5:00] 拿不准的 绝对不能当成事实写进去工具给它配上网页搜索和抓取最后也是最重要的一点输出结构必须固定比如要求它必须输出五个字段核心结论关键事实信息来源真一点和带确认相为什么输出结构这么关键因为在一条流水线上,下游的写稿Agent正等着接收这份数据了如果调研Agent今天给你一段总结,明天给你甩几个链接后天又把自己的猜测混在事实里,下游的程序根本没法稳定解析很多项目越跑越稳往往不是因为换了多昂贵的大模型而是因为每一个agent的职责边界变得极其清晰输入输出变得极其规范刚才提到了工具,咱们顺着往下说搜索网页、读写文件、查数据库这些都是工具在设计工具层的时候,我一直坚持一个原则,一个工具只干一件极其明确的是搜索就是存搜索,抓取就是存抓取千万别搞那种大包大懒的全能工具你要知道,模型在挑选工具的时候是靠阅读工具的描述来做决定的工具的功能越臃肿,你的描述就越难写模型调错的概率就成指数级上升而且工具的输入输出也得规规矩矩,比如网页搜索进去的是一个搜索词,出来的必须是标题,摘要。链接这种结构化的数据而不是一大段乱七八糟的自然语言每一个工具都必须能够脱离agent独立运行和测试这样一旦系统卡壳了你马上就能排查出到底是工具本身的接口挂了还是Agent老子抽风选错了工具有了工具咱们还得聊聊一个更高级的概念技能很多人分不清工具和技能的区别其实很好理解,工具是你具备的能力,而技能是你打胜仗的方法论抓取网页是个工具保存文件也是个工具,但是如何深度调研一款刚发布的AI产品,这就是一个技能。因为这个技能里面固化了一套被验证过的标准作业流程先去查官网,再去翻开发文档然后去社区看用户的真实讨论最后把冲突的信息做交叉比对汇总成报告 工具解决的事 这是我能不能干而技能解决的是,这是怎么干才最靠谱?一个项目长期跑下来你真正积累的核心资产绝对不是那一堆到处都能找到的工具代码而是这些经过无数次实战检验的技能包下次换个新话题Agent直接调用这个技能包,不需要从头试错聊完了知心层咱们来看看数据层也就是上下文和记忆现在很多人做agent有一种直练,觉得既然是高级项目就必须得上销量数据库,必须得搞RAG检索增强大家先冷静一下咱们先回答第一个问题在处理眼下这个任务时模型需要知道什么用户刚输入的指令刚才抓回来的网页当前流程走到了哪一步这些都叫上下文他们只为当前这一次任务服务用完就可以丢了然后咱们再看第二个问题这次任务结束后有哪些信息是真正有价值需要留到下个月甚至明年用的比如用户特别讨厌某种文风或者某个项目有特殊的排版要求这些长期规则才够资格进入记忆库反过来那些临时的报错信息过期的网页缓存存下来纯属浪费空间所以上向文和记忆在设计上必须分开在项目早期用简单的文本文件或者轻量级数据库完全足够了你的数据量真的大到跨任务检索出现瓶颈了再去引入限量数据库也完全来得及记住不是让模型记住的东西越多越好如果他把错误的经验记牢了你后面想纠正它会极其痛苦说到让模型听话就不得不提提示词的管理在真正的工程项目里千万别把所有的规则和背景全都塞进一段几千字的操场提示词里聪明的做法是把它拆开拆成系统角色当前任务、异形约束、优秀势力以及输出格式为什么要拆开呢因为一旦结果不如预期你知道该去调哪里比如你发现agent总是喜欢火边乱造那你就去修改硬性约束那一段而不是把整个提示词推到重写更关键的是拆分后的提示词必须全部接入Git进行版本控制在工程化视角里,提示词根本不是聊天框里随便敲的几句话它是agent的程序逻辑的核心组成部分能不能把提示词当代码一样去管理?这就是业余demo和专业项目最大的分水灵代码写完了,提示词也管好了接下来就是测试传统的软件测试比如函数能不能跑通接口通不通这些肯定要做但一件的项目有个天坑代码一录绿灯不代表任务干得漂亮比如调研agent洋洋洒洒写了3000字报告程序没报错单元测试全过但你仔细一看里面引用的数据是三年前的甚至还出现了严重的幻觉从程序员的角度看代码跑通了但从业务的角度看这是彻底砸了所以除了常规测试你必须引入评估机制你需要准备几十个甚至上百个真实的业务考题固定下来每次你换了新的大模型改了提示词或者加了新技能就把这道考题完整重跑一遍系统会自动评估它的事实准确率工具调用正确率以及消耗的成本和时间只有当方案B的综合得分确实高于方案A你才能拍着胸脯说这次优化是成功的否则光评一句我感觉他好像变聪明了在严谨的工程面前是没有任何意义的而且这道考题本身也要做版本管理遇到线上翻车的真实案例,通明之后 [10:00] 你加进提供你让系统在真实的错误中不断进化最后当你的项目终于部署上线了千万别松一口气上限只是个开始,可观测性才是你不断迭代的眼睛你必须在后台能清楚的看到优户发了什么指令,工作流走到了哪一步Agent在那个瞬间为什么决定用这个工具?工具返回了什么数据?整个过程花了多少token和多少钱?为什么飞机不可,因为Agent不是传统程序同样的输入由于模型状态或者网络波动,输出可能完全不同。如果用户跑来投诉说结果不对你调出后台电路一看,发现agent逻辑非常完美只是搜索工具恰好返回了一个过期的网页这时候你就知道,该去优化的是数据源而不是像无头长眼一样去改提词词如果没有这道监控和日志,你很容易陷入一出bug,就改提示词,越改越乱的死循环。真正的开发节奏是,运行、记录、评估、修改,然后再评估。咱们最后把这整道逻辑创一遍,动手前先定好需求边界,写代码前列好项目规矩,把确定性的流程交给工作流不确定性的判断交给智能体工具 只做基础动作 技能沉淀 业务经验上下文解决眼下的事 记忆只留核心资产提示时要分层管理并控制版本常规测试保证系统不崩溃专项评估保证业务能达标最后,靠着完善的监控体系持续打磨当你把这一整套体系真正在项目里运转起来你的agent才会从一个只能用来演示的玩具慢慢生长为一个代码可维护功能可扩展,真正敢交付给客户使用的商业产品说到底,咱们做Agent的工程核心永远不是研究怎么让大模型去调一次接口而是怎么用工程化的手段让一个天生充满不确定性的AI能够长期稳定的帮你完成确定的业务目标希望今天的拆解能给大家带来一些真正落地的启发