《实用笔记：构建高效AI智能体——架构模式及》
《实用笔记：构建高效AI智能体——架构模式及适用于采用该模式的团队的契约、校验机制与即用代码模块》的操作指南。
本指南将逐步展示如何从原始材料构建出可运行的系统，用于《构建高效AI智能体：架构模式与实现框架》一书。重点在于可操作的步骤、明确的检查点，以及可直接放入代码仓库的代码，无需猜测其用途。 在概览阶段，应在修改代码之前明确输入参数、各步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行相应步骤，而无需推测隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在系统从演示环境过渡到共享环境时出现意外费用。
1. 什么是AI智能体？
在处理“1. 什么是”这一阶段时，首先写下相关契约：所需的输入参数、成功标志，以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作人员重新执行后续节点时，恢复流程不应再次计费相同的大型语言模型调用。
2. 核心智能体架构
在处理“2 The Core Agent”阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个后续节点时，恢复流程不应再次调用相同的LLM接口。
用户或系统界面
在处理用户界面或系统接口阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 建议采用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在处理用户界面或系统接口阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及Token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外收费。
智能体运行时
将 Agent 运行时阶段视为可度量的对象来处理，其效果最佳。在扩大范围之前，先记录一份理想的运行日志、一个故障案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放于一个位置，这样操作人员无需查看整个架构即可进行审计。 保持架构状态的简洁性与类型化。嵌套的数据结构会掩盖是哪个节点修改了哪个字段，且在中断后会导致恢复失败。
3. 模型层
将“模型层”阶段视为可度量的对象来处理时，效果最佳。在扩大范围之前，先记录一个成功的用例、一个失败案例以及回滚说明。同时记录正常流程和恢复流程的文档。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。为每轮对话和每次会话设定token预算。智能代理工具会大量消耗上下文，设置上限可以避免演示过程变成意外的费用账单。
4. 工具：将模型转化为智能代理
将“4种工具驱动模型”阶段视为可度量的工作面时，其效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出错时，故障应指向单一责任主体，而非复杂的流程链。 为每轮操作和每次会话设定代币预算。智能工具会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。 将“4种工具驱动模型”阶段视为可度量的工作面时，其效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 在功能结果旁记录执行时间以及代币或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。
search_leads()
get_account()
get_customer_history()
get_recent_emails()
create_opportunity()
schedule_meeting()
generate_proposal()
5. 模式1：使用工具的智能体
对于模式1的第5阶段，在修改代码之前需明确输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个流程即可进行审计。 在网关处进行身份验证，在数据层再次授权。仅凭承载令牌并不足以界定租户边界。
User
↓
Agent
↓
LLM
↓
Choose Tool
↓
Execute Tool
↓
Tool Result
↓
LLM
↓
Final Response
get_weather("Chicago", "tomorrow")
6. 模式2：ReAct
在6模式2 ReAct阶段，修改代码之前需明确输入参数、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。
Goal
↓
Reason
↓
Action
↓
Observation
↓
Reason
↓
Action
↓
Observation
↓
Final Answer
User Goal:
Find our highest-value customer with an unresolved support case.
Reason:
I need customer revenue data.Action:
query_customer_database()Observation:
Customer A has the highest revenue.Reason:
Now I need unresolved support cases.Action:
search_support_cases(customer_a)Observation:
Two unresolved cases found.Final Answer:
Customer A is the highest-value customer currently
associated with unresolved support cases.
7. 模式3：计划与执行
在7模式3的规划与执行阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在7模式3的规划与执行阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转为实际使用环境时出现意外账单。
环境。Goal:
Prepare me for tomorrow's meeting with Acme Corp.
1. Retrieve account information
2. Review recent opportunities
3. Retrieve previous meeting notes
4. Review recent emails
5. Identify unresolved issues
6. Find relevant company news
7. Generate meeting briefing
User Goal
↓
Planner
↓
Task Plan
↓
Executor
↓
Tools
↓
Results
↓
Evaluator
↓
Final Output
8. 模式4：路由器架构
在处理模式4的8个路由器阶段时，首先列出相关约定：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次对同一次LLM调用收费。
┌── HR Agent
│
User → Router ────┼── Finance Agent
│
├── IT Support Agent
│
└── Sales Agent
9. 模式5：监管代理与工作代理
在处理第9阶段的Pattern 5 Supervisor时，首先写下相关约定：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个节点时，恢复流程不应再次调用相同的LLM接口。
Research Agent
↑
│
User → Supervisor → Data Agent
│
↓
Report Agent
10. Pattern 6：代理式RAG
在完成第10阶段的模式6智能体开发时，首先需明确相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 相较于庞大的脚本，应优先选择小型且可测试的单元。当某个步骤出现故障时，故障点应指向单一责任模块，而非复杂的流程链。 在调整提示词之前，先使用固定的问题集测试召回率。仅仅更换提示词很难解决检索效果不佳的问题。 在完成第10阶段的模式6智能体开发时，首先需明确相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。
Question
↓
Vector Search
↓
Relevant Documents
↓
LLM
↓
Answer
Question
↓
Agent
↓
Do I need retrieval?
↓
Which source?
↓
Search
↓
Evaluate results
↓
Enough information?
↓ ↓
Yes No
↓ ↓
Answer Search Again
11. 模式7：反思与自我评估
模式7的反思阶段若被视为可度量的对象，效果会更好。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放，以便操作人员无需查看整个结构就能进行审计。 保持数据结构的层次简单且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致流程无法继续。
Generate Answer
↓
Evaluate Answer
↓
Is it sufficient?
↓ ↓
Yes No
↓ ↓
Return Improve
12. 内存架构
将12层内存架构视为可测量的对象时，其效果最佳。在扩大范围之前，先记录一个成功的用例、一个失败案例以及回滚说明。 同时记录正常流程和恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。 保持图结构的状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在发生中断后导致流程无法继续。
工作内存
将工作记忆阶段视为可测量的界面时，其效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 相较于庞大的脚本，应优先选择小型且可测试的单元。当某一步骤出现故障时，故障原因应能明确指向某个具体责任方，而非复杂的流程链。 保持图表状态简洁且具有类型定义。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息，还会在进程中断后导致无法继续执行。 将工作记忆阶段视为可测量的界面时，其效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解这些成本信息，可避免在从演示环境过渡到共享环境时出现意外费用。
对话记忆
在对话记忆阶段，应在修改代码之前明确输入内容、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放，以便操作人员无需查看整个系统结构即可进行审核。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。
长期记忆
在长期记忆阶段，修改代码之前需明确输入内容、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。
情景记忆
在情景记忆阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。 在情景记忆阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。
13. 状态往往比内存更重要
在处理“状态往往很重要”这一阶段时，首先写下相关约定：所需的输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个流程就能进行审计。 在耗时较高的步骤之后设置检查点。当操作人员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。
state = {
"goal": "",
"user_id": "",
"plan": [],
"completed_tasks": [],
"tool_results": {},
"approval_status": None,
"errors": [],
"final_answer": None
}
14. 基于图的智能体架构
在完成14种基于图的智能体架构的设计阶段时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与故障恢复流程。重试机制、人工干预环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个后续节点时，恢复流程不应再次调用相同的大型语言模型。
Start
↓
Classify Request
↓
Retrieve Data
↓
Analyze
↓
Risk Check
↓
Need Approval?
↓ ↓
Yes No
↓ ↓
Human Execute
Approval ↓
↓ Finish
Execute
↓
Finish
15. 人工干预架构
在完成15个“人在回路”架构阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在完成15个“人在回路”架构阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及Token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外收费。
Agent Recommendation
↓
Policy Check
↓
High-Risk Action?
↓ ↓
Yes No
↓ ↓
Human Execute
Approval
↓
Execute
16. Agent规范
将“16个Agent规范”视为可度量的标准来运用效果最佳。在扩大范围之前，先记录一份优秀案例、一个失败案例以及回滚说明。 配置应置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放，以便操作员无需查看整个架构即可进行审计。 保持架构状态的简洁性与类型化。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息，且在中断后会导致恢复失败。
输入规范
将 Input Guardrails 阶段视为可度量的框架使用效果最佳。在扩大范围之前，先记录一份理想的处理流程、一个失败案例以及回滚说明。同时文档化正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的内容。保持图结构的状态简洁且类型明确，嵌套的数据块会掩盖具体是哪个节点修改了哪个字段，还会在中断后导致流程无法继续。
工具防护机制
将 Tool Guardrails 阶段视为可度量的界面使用效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出现故障时，故障应指向单一责任模块，而非复杂的流程链。 为工具提供结构明确的架构以及清晰的副作用标签。主机需要在自动批准之前知道哪些调用会修改状态。 将 Tool Guardrails 阶段视为可度量的界面使用效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
输出规范
在“输出管控”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放，以便操作人员无需查看整个流程即可进行审计。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务流程的完整性。
执行管控
在“执行防护栏”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理都是产品不可或缺的部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。
17. 实现框架
在17个实施框架阶段中，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在17个实施框架阶段中，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免从演示环境过渡到实际使用环境时出现意外账单。
环境。Python
+
LLM API or local model
+
Functions
+
FastAPI
+
Database
基于图的框架
在处理基于图的框架阶段时，首先写下相关规范：所需的输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放，以便操作员无需查看整个框架结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。
多智能体框架
在处理多智能体框架阶段时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 同时记录正常流程与故障恢复流程。重试机制、人工干预环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 在成本较高的操作之后设置检查点。当操作员重新尝试某个节点时，恢复流程不应再次调用相同的大型语言模型。
企业级 AI 编排平台
在开发企业级 AI 编排平台时，首先需明确相关规范：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 建议采用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在开发企业级 AI 编排平台时，首先需明确相关规范：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外收费。
18. 实用实现框架
在“18 实用实现”阶段，将其视为可度量的对象会更为有效。在扩大范围之前，先记录一份最佳实践案例、一个故障实例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放于一处，这样操作人员无需查看整个系统结构即可进行审计。 保持系统状态的扁平化与类型化。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息，还会导致在中断后无法继续执行。
第一步：明确目标
第一步“定义阶段”若被视为可度量的对象，效果最佳。在扩大范围之前，先记录一个成功的用例、一个失败案例以及回滚说明。同时将正常流程与恢复流程记录下来。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的内容。要保持图表状态简洁且具有类型定义，嵌套的数据块会掩盖哪个节点编写了哪个字段的信息，还会在中断后导致流程无法继续。
第二步：定义智能体的职责
将“第2步：定义阶段”视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出现故障时，故障应指向单一责任主体，而非复杂的流程链。 保持图表状态简洁且具有类型定义。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息，还会在流程中断后导致无法继续执行。 将“第2步：定义阶段”视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外费用。
Retrieve account information
Retrieve opportunities
Analyze customer communication
Retrieve open support issues
Generate meeting briefing
Recommend discussion topics
Cannot modify CRM records
Cannot send email
Cannot change pricing
Cannot create contracts
19. 第3步：定义工具
在19的第三步“定义”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。 在网关处进行身份验证，在数据层再次授权。仅凭承载令牌并不足以界定租户边界。
get_account(account_id)
get_opportunities(account_id)
get_support_cases(account_id)
get_email_history(account_id)
search_company_news(company_name)
manage_customer()
get_customer_profile()
20. 第四步：设计控制流
在20步法中的第4阶段设计时，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。
21. 第5步：添加状态与内存
在21步骤的5“添加”阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非冗长的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在21步骤的5“添加”阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外账单。
Conversation state
Task state
User preferences
Long-term knowledge
Audit history
22. 第6步：添加可观测性
在执行第22步的“添加”阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作人员重新尝试后续节点时，恢复流程不应再次对相同的LLM调用收费。
Request
Agent decision
Model used
Prompt version
Tool selected
Tool input
Tool output
Execution time
Token usage
Cost
Errors
Retries
Final response
Human overrides
Request ID: 78425
Step 1:
Intent → Customer Meeting PreparationStep 2:
Tool → get_account()Step 3:
Tool → get_opportunities()Step 4:
Tool → search_support_cases()Step 5:
LLM → Generate briefingTotal execution: 4.8 seconds
Tool calls: 3
Model calls: 2
23. 第7步：评估智能体
在完成第23步的“阶段7：评估”时，首先写下相关约定：所需的输入参数、成功标志，以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离原定方向。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误消息处理都是产品本身的组成部分，而非后续需要补充的功能。 在成本较高的步骤之后设置检查点。当操作员重新尝试某个后续节点时，恢复流程不应再次调用相同的LLM接口。
任务完成
在处理任务完成阶段时，首先需明确相关规范：所需的输入参数、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 建议使用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在处理任务完成阶段时，首先需明确相关规范：所需的输入参数、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。
工具选择
将工具选择阶段视为可度量的指标体系时，其效果最佳。在扩大范围之前，先记录一份优秀的处理案例、一个故障实例以及回滚说明。 应将配置与应用程序代码分开。环境文件、密钥存储和功能标志应集中存放于一处，以便操作人员无需查看整个系统结构即可进行审计。
工具准确性
现实依据性
安全性
效率
延迟
成本
24. 故障恢复
Tool Call
↓
Success?
↓ ↓
Yes No
↓ ↓
Continue Retry
↓
Still Fails?
↓ ↓
Yes No
↓ ↓
Fallback Continue
↓
Escalate
25. 多智能体系统：谨慎使用
Supervisor
├── Financial Analysis Agent
├── Legal Analysis Agent
├── Market Research Agent
└── Report Generation Agent
Search Agent
Thinking Agent
Tool Agent
Summary Agent
Response Agent
26. 企业级智能体架构
User
↓
Agent Gateway
↓
Identity / Access
↓
Router
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Sales Agent HR Agent Finance Agent
↓ ↓ ↓
Agent Runtime
↓
┌──────────┼──────────┐
↓ ↓ ↓
RAG Tools Memory
↓ ↓ ↓
Knowledge APIs Databases
Base
↓
Policy Engine
↓
Human Approval Layer
↓
Observability
↓
Evaluation
27. 确定性软件与概率性人工智能
Probabilistic Intelligence
+
Deterministic Control
=
Reliable Agentic System
28>从工作流开始，再逐步增加自主性
第一阶段——助手
第二阶段——会使用工具的助手
第三阶段——引导式智能体
第4阶段 — 自主工作流
第5阶段 — 多智能体系统
29. 什么造就了高效的AI智能体？
30. 总结与思考
架构概要
AI Agent
│
├── Model
├── Instructions
├── Context
├── Tools
├── Retrieval
├── Memory
├── State
├── Planning
├── Orchestration
├── Guardrails
├── Human Oversight
├── Observability
└── Evaluation