《实用笔记》：具备自我提升能力的智能体AI应用——反馈循环
《实用笔记》操作指南：具备自我提升能力的智能体AI应用——反馈循环：适用于采用该模式的团队的合同、检查项以及即插即用代码模块。
可将此内容作为《自我提升的智能代理应用——反馈循环集成》中理念面向操作人员的重构版本：清晰的阶段划分、有序的代码模块以及能在交接过程中保留的恢复说明。 将“概览”阶段视为可量化的界面使用效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
智能代理不应成为学习系统
在进入“Agent不应执行”阶段之前，需先明确输入参数、该步骤的负责人以及终止标准，然后再修改代码。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，这样操作人员无需查看整个流程即可进行审核。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不能保证业务的完整性。
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
三种不同的反馈循环
在“三种不同反馈循环”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及退出标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
1. 运行时自愈
在第一个运行时自愈阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止条件。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在第一个运行时自愈阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止条件。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境过渡到共享环境时出现意外账单。
。Tool failed
↓
Retry
↓
Retry
↓
Retry
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
应在操作前进行验证，而非仅在操作之后
在处理“操作前验证”阶段时，首先明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离既定要求。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作人员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型接口。
工具输出同样属于不可信输入
在处理“工具输出阶段”时，首先需写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离原定方向。 同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及错误消息处理都是产品本身的组成部分，而非后续需要补充的功能。 需为每次调用记录工具名称、参数哈希值、响应延迟以及最终结果。没有这些记录，调试过程将会浪费大量时间。
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
将验证器与评估器分开
在着手将验证器与处理阶段分离时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合预期。 相较于庞大的脚本，应优先选择小型且易于测试的单元。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在着手将验证器与处理阶段分离时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合预期。 除了功能结果外，还需记录执行时间以及Token或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
修复应改变策略
将“修复应改变阶段”这一机制视为可度量的界面使用效果最佳。在扩大范围之前，先记录一份理想的运行日志、一个故障案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 保持系统状态的结构简洁且具有类型约束。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会导致在出现中断后无法继续执行。
Search policy
↓
Generate recommendation
↓
Fail validation
Search policy
↓
Generate recommendation
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
same failure
+
same strategy
+
same evidence
=
do not retry
衡量修复是否真正有效
将“修复是否真正有效”这一评估视为可测量的指标时效果最佳。在扩大范围之前，先记录一份理想的处理流程、一个故障案例以及回滚说明。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续补充的功能。 保持图表状态简洁且类型明确。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致流程无法继续。
quality score = 0.54
quality score = 0.55
quality score = 0.56
delta = score_after_repair - score_before_repair
small delta
+
small delta
=
human review or safe failure
人工干预是一种路由策略，而非例外情况
“人在回路”这一路由阶段作为可度量的对象来处理时效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 相较于复杂的脚本，应优先选择小型且可测试的单元。当某一步骤出现故障时，故障原因应能明确指向某个具体责任方，而非整个错综复杂的流程。 保持图结构的状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点编写了哪个字段的信息，还会在流程中断后导致无法继续执行。 “人在回路”这一路由阶段作为可度量的对象来处理时效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 除了功能结果外，还需记录执行时间以及令牌或查询的成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外费用。
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
2. 跨多次运行积累经验
在“跨阶段体验式学习”模式中，修改代码之前需明确输入参数、各步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行相应步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储及功能标志应集中存放，以便操作人员无需查看整个系统结构即可进行审核。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
反馈并非真相
在“反馈非真相”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品不可或缺的部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
一些最宝贵的反馈会在后期出现
在“Some of the Best”阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 相较于庞大的脚本，更应优先选择小型且可测试的单元。当某个步骤失败时，故障原因应能明确指向单一责任方，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。仅靠编译时的配置并不足以确保业务的完整性。 在“Some of the Best”阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外账单。
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
内存需求治理
在处理内存需求治理阶段时，首先需明确合同条款：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次对相同的LLM调用收费。
内存使用情况分析
在处理 Profile 内存阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离原定设计。
同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。
在成本较高的操作之后设置检查点。当操作员重新尝试某个后续节点时，恢复流程不应再次调用相同的 LLM 接口。
情景记忆
在处理情景记忆阶段时，首先需写下相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 优先选择小型、可测试的单元，而非庞大的脚本。当某一步骤失败时，故障应指向单一责任点，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在处理情景记忆阶段时，首先需写下相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。
程序记忆
将程序记忆阶段视为可测量的表层结构时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，以便操作人员无需查看整个结构就能进行审计。 保持图结构的扁平化与类型化。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，且在中断后会导致恢复失败。
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
学习到的记忆绝不能覆盖权威知识
将“学习型内存”视为可测量的对象来处理时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 同时记录正常流程和恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续的优化工作。 保持图结构的状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致流程无法继续。
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
内存可能会过时
将“内存可能过时”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的运行日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 保持图结构的状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在进程中断后导致无法继续执行。 将“内存可能过时”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的运行日志、一个故障案例以及回滚说明。 在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
3. 离线学习层面
在“离线学习”阶段的第三步中，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，这样操作人员无需查看整个流程即可进行审核。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
并非所有故障都是提示问题
在“并非所有失败都如此”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 当下一步操作为代码编写或工具调用时，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文字描述。
Graph rule:
Policy retrieval must occur before this decision.
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
评估是反馈循环的核心
在“评估是核心”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在“评估是核心”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。ts。
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
Agent A
search -> answer
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
不要依赖单一的LLM评估器
在处理“不要依赖单一”这一阶段时，首先需写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 应将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 需缓存稳定的系统指令和工具架构。重复发送相同的开头信息是导致资源浪费的常见原因。
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
可观测性是学习架构的一部分
在完成“可观测性是重要组成部分”这一阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与故障恢复流程。重试机制、人工审核环节以及死信处理都属于产品功能的一部分，而非后续需要补充的内容。 在成本较高的操作之后设置检查点。当操作员重新尝试某个节点时，恢复流程不应再次调用相同的大型语言模型。
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
为何只读型代理事件如此重要
在处理“为何使用只读代理事件”这一阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 建议采用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。 在处理“为何使用只读代理事件”这一阶段时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及token或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。
run_id
agent
release
outcome
latency
tool count
repair count
cost
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
实现可重复性不仅需要提示词版本
“实现可重复性不仅需要……”这一阶段若被视为可测量的指标，则效果最佳。在扩大范围之前，先记录一份理想的输出结果、一个失败案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放，这样操作人员无需查看整个系统结构即可进行审计。 为每轮对话和每次会话设定令牌预算。智能工具往往会大量消耗上下文资源；设置上限可避免演示过程变成意外的费用账单。
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
控制平面：改进如何获得正式上线资格
当控制平面被视为可测量的界面时，stage功能表现最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 同时记录正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的功能。 保持图结构的层次简单且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致流程无法继续。
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
金丝雀发布对总结经验同样重要
“Lessons Need Canary Releases”阶段若被视为可度量的评估面，效果最佳。在扩大范围之前，需记录一份完美的操作日志、一个故障案例以及回滚说明。 应优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤失败时，故障应能指向单一责任模块，而非复杂的流程链。 保持图表状态简洁且具有类型定义。嵌套的数据结构会掩盖具体是哪个节点修改了哪个字段，还会在流程中断后导致无法继续处理。 “Lessons Need Canary Releases”阶段若被视为可度量的评估面，效果最佳。在扩大范围之前，需记录一份完美的操作日志、一个故障案例以及回滚说明。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外费用。
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
最终架构
在“最终架构”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
这对“自我提升型人工智能”意味着什么
在“这会带来什么变化”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
实际实施步骤
在“实际实现流程”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非冗长的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。 在“实际实现流程”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程发生变化时出现意外账单。
将情绪表达传递到共享环境。Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
总结思考
在完成总结思考阶段时，首先列出相关规范：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作员重新执行后续节点时，恢复流程不应再次计费相同的大型语言模型调用。
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
操作清单
在完成操作清单阶段时，首先列出相关规范：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。
将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，杜绝默许的半完成状态。
在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。
锁定依赖项的版本，并记录用于运行演示的镜像摘要。可重复性远胜于经验主义。
在功能结果旁记录执行时间以及token或查询成本。提前明确成本有助于避免从演示环境过渡到共享环境时出现意外收费。
在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。
在推广该技术栈之前，应先冻结版本，为关键流程记录标准输出日志，并明确回滚步骤。共享环境需要设置速率限制、租户验证机制，以及负责密钥轮换的明确责任人。与其展示花哨的一次性演示，不如注重扎实的可靠性。
针对 da99b44a5b86 的批量说明：请将提供商密钥移出代码仓库，设定单会话令牌上限，并将日志存储在评估用示例文件旁，以便后续模型更换时保持数据可比性。