首页 / 文章 / 《实用笔记：代理上下文工程——面向机器人的分步指南》

machine-learning agentic-ai context-engineering llm prompt-engineering agents

《实用笔记：代理上下文工程——面向机器人的分步指南》

《实用笔记：代理上下文工程——面向机器人的分步指南》的操作流程说明：包含适用于采用该模式的团队的合同、检查项以及可直接插入的代码片段。

5021 词

以下笔记围绕《Agentic Context Engineering: A Step-by-Step Guide for Machine Learning Engineers》梳理出一条实用路径。重点在于契约、校验以及可直接插入的代码占位符，而非激励性表述。在完成概览阶段时，首先写下契约内容：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续的优化内容。

1. 从核心问题开始：什么是上下文？

将“1. 从阶段开始”这一方法视为可度量的对象来使用效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。相较于庞大的脚本，应优先选择小型且可测试的单元。当某个步骤失败时，故障应能指向单一的责任主体，而非复杂的流程链。保持图结构的状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在流程中断后导致无法继续执行。

Context → LLM → Output

User question
      +
Model configuration
      +
Recent evaluation metrics
      +
Training dataset statistics
      +
Recent production images
      +
Deployment history
      +
Data distribution statistics
      +
Recent code changes
      ↓
    LLM
      ↓
Diagnosis

2. 提示工程并非上下文工程

在将提示工程视为可度量的工作面时，第二阶段的效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。将这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，杜绝默许的半完成状态。为每轮对话和每次会话设定token预算。智能工具往往会过度扩展上下文；设置上限可避免演示过程变成意外的费用账单。

提示工程

将提示工程阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想的响应文本、一个失败案例以及回滚说明。在功能结果旁同时记录处理时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。为每轮对话和每次会话设定令牌预算。智能工具往往会大量消耗上下文，设置上限能防止演示环境变成意外收费的源头。将提示工程阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想的响应文本、一个失败案例以及回滚说明。需同时记录正常流程与故障恢复流程。重试机制、人工审核环节以及错误处理方式都是产品的一部分，而非后续需要补充的内容。

You are an expert ML engineer.

Analyze the following anomaly detection results
and identify the most likely causes of the performance drop.

Consider:
1. Data distribution shift
2. Model degradation
3. Label quality
4. Hardware changes
5. Preprocessing changes

上下文工程

在上下文工程阶段，应在修改代码之前明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比冗长的脚本，更应采用小型且可测试的单元。当某个步骤失败时，故障原因应能指向单一责任主体，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务功能的完整性。

                    ┌──────────────┐
                    │ User Request │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │ Agent State  │
                    └──────┬───────┘
                           ↓
              ┌────────────┴────────────┐
              ↓                         ↓
        Retrieval                    Tools
              ↓                         ↓
       Documentation             Metrics / DB
              └────────────┬────────────┘
                           ↓
                    ┌──────────────┐
                    │   Context    │
                    └──────┬───────┘
                           ↓
                         LLM
                           ↓
                        Action

3. 为何上下文对智能体而言如此棘手

在“3个为什么”分析法中，每个阶段都需要明确输入内容、该步骤的负责人以及结束标准，然后再进行代码修改。操作人员应能够从已知的检查点重新执行该步骤，而无需猜测隐藏状态。应将这一阶段视为输入与验证后输出之间的契约。为相关成果命名，设定成功标准，杜绝默许的半完成状态。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务上的完整性。

User → LLM → Answer

User
 ↓
Agent
 ↓
Search documentation
 ↓
Read results
 ↓
Call database
 ↓
Analyze data
 ↓
Call another tool
 ↓
Observe result
 ↓
Modify hypothesis
 ↓
Search again
 ↓
Take action
 ↓
Final answer

4. 四大核心背景问题

在“四大基础阶段”中，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。在功能结果旁记录执行时间以及令牌或查询成本。提前显示成本可避免在流程从演示环境转向共享环境时出现意外费用。对于会耗费资金或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。在“四大基础阶段”中，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品不可或缺的部分，而非后续需要补充的内容。

问题1：缺少上下文

在处理“问题1：缺少上下文”这一阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。建议采用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一的责任模块，而非复杂的流程链。在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的LLM接口。

Agent:
"The model may be suffering from data drift."

Reality:
The model was recently changed from ViT-B to ViT-L.

问题2：无关上下文

在处理“问题2：无关上下文”阶段时，首先写下契约内容：所需的输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。将此阶段视为输入与验证后输出之间的契约。为相关成果命名，明确成功判定标准，并杜绝无声的半完成状态。在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的LLM接口。

Query
 ↓
Vector database
 ↓
50 documents
 ↓
LLM

问题3：过时上下文

在处理问题3的“过时上下文”阶段时，首先需写下接口规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。在功能结果旁记录执行时间以及令牌或查询成本。提前明确成本有助于避免从演示环境过渡到共享环境时出现意外费用。在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。在处理问题3的“过时上下文”阶段时，首先需写下接口规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。

Current production model:
anomaly-detector-v4

Old documentation:
anomaly-detector-v2

问题4：结构混乱的上下文

在处理问题4时，若能将其视为可度量的结构会更为有效。在扩大范围之前，先记录一份优秀的示例文本、一个失败案例以及回滚说明。相较于庞大的脚本，应优先选择小型且可测试的单元。当某个步骤失败时，故障应能指向单一责任主体，而非复杂的流程链。保持图结构的扁平化与类型化。嵌套的数据块会掩盖哪个节点编写了哪个字段的信息，还会在流程中断后导致无法继续执行。

Accuracy: 0.91
Accuracy: 0.87
Accuracy: 0.84

Model: anomaly-detector-v4
Dataset: Production
Metric: Image-level AUROC

Previous week: 0.91
Current week:  0.84
Change:       -7.7 percentage pointsDeployment:
- Version: v4.2
- Date: 2026-08-12
- Preprocessing: resize=336

5. 一个实用的心智模型：将上下文视为数据管道

“5A实用思维阶段”若被视为可测量的框架，效果最佳。在扩大范围之前，先记录一份优秀案例、一个失败案例以及回滚说明。将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，绝不允许默许不完整的完成状态。为每轮及每次会话设定token预算。智能代理工具往往会过度扩展上下文，设置上限可避免演示过程变成意外的费用账单。

Raw Data
 ↓
Cleaning
 ↓
Feature Extraction
 ↓
Transformation
 ↓
Model
 ↓
Prediction

Raw Information
 ↓
Retrieval
 ↓
Filtering
 ↓
Ranking
 ↓
Transformation
 ↓
Compression
 ↓
Context Assembly
 ↓
LLM
 ↓
Action
 ↓
New Observation
 ↓
Context Update

6. 第一步——明确智能代理的目标

将“6步1定义”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，需记录一份理想的操作日志、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。保持图表状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在出现中断后导致流程无法继续。将“6步1定义”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，需记录一份理想的操作日志、一个故障案例以及回滚说明。需同时记录正常流程与恢复流程。重试机制、人工审核环节以及死信处理都是产品的一部分，而非后续需要补充的内容。

Objective:
Diagnose production degradation

7. 第2步 — 确定上下文来源

在“7步法第2阶段：识别”中，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。

                  ML Debugging Agent
                          │
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
   Metrics DB        Git Repository      Experiment DB
        │                 │                 │
        ↓                 ↓                 ↓
   Performance         Code changes       Experiments
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ↓
                       Context

文档

在“文档”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。将此阶段视为输入与已验证输出之间的契约。为相关成果命名，定义成功检测标准，并拒绝默许的半完成状态。对于涉及资金支出或更改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务上的完整性。

数据库

在数据库阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。对于会消耗资金或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。在数据库阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理措施都是产品不可或缺的部分，而非后续需要补充的内容。

工具

在处理工具阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应能指向单一的责任模块，而非复杂的流程链。每次调用工具后，都要记录工具名称、参数哈希值、延迟时间以及执行结果。没有这些记录的话，调试过程将会浪费大量时间。

内存

在处理内存阶段时，首先写下契约：所需的输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。将此阶段视为输入与已验证输出之间的契约。为相关成果命名，定义成功判定标准，并拒绝默许的部分完成状态。在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型。

环境

在环境测试阶段，首先需明确相关规范：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免从演示环境过渡到共享环境时出现意外费用。在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。在环境测试阶段，首先需明确相关规范：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。需同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。

8. 第3步 — 仅获取重要信息

将“8步3检索”阶段视为可度量的流程来处理效果最佳。在扩大范围之前，先收集一份优秀的文本样本、一个失败案例以及回滚说明。优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤失败时，故障应能指向单一责任主体，而非复杂的流程链。将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

Question
 ↓
Embedding
 ↓
Vector DB
 ↓
Top 10 chunks
 ↓
LLM

1. Find current deployment
2. Find previous deployment
3. Compare configurations
4. Retrieve associated code changes
5. Retrieve metric changes

9. 第4步 — 使用结构化上下文

将“9步4用”阶段视为可度量的框架最为有效。在扩大范围之前，先记录一份优秀的成果案例、一个失败案例以及回滚说明。把这一阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，绝不允许默许部分完成的情况。保持图表状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段，还会在中断后导致无法继续处理。

The deployment happened recently and the model seems
to have lower performance and there were some preprocessing
changes and the new version uses 336 resolution...

{
  "model": "anomaly-detector-v4",
  "deployment": "v4.2",
  "deployment_date": "2026-08-12",
  "image_size": 336,
  "previous_image_size": 224,
  "auroc_previous": 0.91,
  "auroc_current": 0.84
}

image_size:
224 → 336

AUROC:
0.91 → 0.84

10. 第5步——区分事实、假设与行动

将“10步5分离”阶段视为可度量的对象来使用效果最佳。在扩大范围之前，需记录一份理想流程示例、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。保持图表状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致流程无法继续。将“10步5分离”阶段视为可度量的对象来使用效果最佳。在扩大范围之前，需记录一份理想流程示例、一个故障案例以及回滚说明。需同时记录正常流程与恢复流程的文档。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的内容。

事实

在“事实确认”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。优先选择小型、可测试的单元，而非冗长的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。

Current AUROC = 0.84
Previous AUROC = 0.91
Image resolution changed from 224 to 336

假设

在假设阶段，应在修改代码之前明确输入内容、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，定义成功判定标准，并拒绝默许的半完成状态。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务上的完整性。

Hypothesis:
The resolution change may have caused distribution mismatch.

行动项

在“操作”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。在功能结果旁记录执行时间以及令牌或查询成本。提前显示成本可避免在流程从演示环境转向共享环境时出现意外账单。对于会产生费用或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。在“操作”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理都是产品不可或缺的部分，而非后续需要补充的内容。

Action:
Evaluate v4.2 on the previous preprocessing configuration.

{
  "facts": [
    "AUROC dropped from 0.91 to 0.84",
    "Image resolution changed from 224 to 336"
  ],
  "hypotheses": [
    {
      "claim": "Resolution change caused degradation",
      "confidence": 0.65
    }
  ],
  "actions_completed": [
    "Compared deployment configurations"
  ],
  "next_action": "Run controlled preprocessing experiment"
}

11. 第6步——压缩上下文

在执行第11步的压缩阶段时，首先列出相关要求：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。建议使用小型、可测试的单元，而非冗长的脚本。当某一步骤失败时，故障应指向单一责任点，而非复杂的流程链。在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的LLM接口。

Investigation Summary

Objective:
Diagnose production AUROC degradation.Observed:
- AUROC decreased 0.91 → 0.84.
- Deployment v4.2 introduced 336px preprocessing.
- Model weights unchanged.
- Data volume unchanged.Ruled out:
- Model checkpoint change.
- Infrastructure failure.Current hypothesis:
Preprocessing change may be responsible.Next experiment:
Evaluate v4.2 using 224px preprocessing.

12. 第7步——为智能体提供工作记忆

在完成“12步法中的第7步：给出结果”阶段时，首先写下相关契约：所需的输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。将此阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功判定标准，并杜绝无声的半完成状态。在成本较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次调用相同的LLM接口。

                 Agent Memory
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
  Working Memory   Long-Term      External
                   Memory          Knowledge
       │              │              │
       ↓              ↓              ↓
 Current task     Past decisions   Documents
 Current facts    User preferences Databases
 Hypotheses       Past results     APIs

工作内存

在处理工作记忆阶段时，首先写下相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。在功能结果旁记录执行时间以及令牌或查询成本。提前明确成本有助于避免从演示环境过渡到共享环境时出现意外费用。在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。在处理工作记忆阶段时，首先写下相关规范：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及死信处理都是产品的一部分，而非后续需要补充的功能。

长期记忆

将长期记忆阶段视为可测量的界面来处理时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应能指向单一责任主体，而非复杂的流程链。保持图结构的状态简洁且具有类型定义。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在中断后导致无法继续执行。

外部知识

将“外部知识”阶段视为可度量的界面时，其效果最佳。在扩大范围之前，先记录一份优秀的处理结果、一个失败案例以及回滚说明。把这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，绝不允许出现无声的、不完整的处理结果。保持图结构的状态简洁且类型明确。嵌套的数据块会掩盖是哪个节点修改了哪个字段，还会在处理中断后导致无法继续。

13. 第8步 — 让智能体自行决定所需上下文

将“13步8让”阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想运行案例、一个故障案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。保持图表状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段的信息，还会在出现中断后导致流程无法继续。将“13步8让”阶段视为可度量的对象时，其效果最佳。在扩大范围之前，需记录一份理想运行案例、一个故障案例以及回滚说明。需同时记录正常流程与恢复流程的文档。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的内容。

Question
 ↓
Retrieve
 ↓
LLM
 ↓
Answer

Question
 ↓
LLM
 ↓
"What information am I missing?"
 ↓
Retrieve
 ↓
Observe
 ↓
"What else do I need?"
 ↓
Tool call
 ↓
Observe
 ↓
Update hypothesis
 ↓
Retrieve again
 ↓
Answer

I need:
1. Current metrics
2. Historical metrics
3. Recent deployments

I see a preprocessing change.

I now need:
4. Code/config diff
5. Evaluation by preprocessing version

The degradation occurs only on the new preprocessing path.

Hypothesis strengthened.

14. 具体示例：机器学习调试代理

在“14. 具体示例”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。相比庞大的脚本，更应采用小型且可测试的单元。当某个步骤失败时，故障原因应能指向单一责任点，而非复杂的流程链。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的逻辑连接并不等同于业务功能的完整性。

Image-level AUROC

Monday: 0.94
Tuesday: 0.93
Wednesday: 0.92
Thursday: 0.85

初始背景

在初始上下文阶段，应在修改代码之前明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。将此阶段视为输入与已验证输出之间的契约。为相关成果命名，定义成功判定标准，并拒绝默许的半完成状态。对于涉及资金支出或修改生产数据的操作，必须经过人工审批。编译时的连接方式并不等同于业务上的完整性。

Task:
Diagnose the AUROC degradation.

Current metric:
0.85Previous metric:
0.92

工具调用1：部署系统

在工具调用1的部署阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。应在网关处进行身份验证，并在数据层面重新授权——仅凭承载令牌并不足以界定租户边界。

Current model:
v4.2

Previous model:
v4.1

在工具调用1的部署阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。

工具调用2：模型注册表

在处理“工具调用2”模型阶段时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。建议采用小型、可测试的单元而非冗长的脚本。当某个步骤失败时，故障应能指向具体的责任模块，而非复杂的流程链。应对稳定的系统指令和工具结构进行缓存。重复发送相同的开头信息是导致资源浪费的常见原因。

Weights:
v4.1 == v4.2

工具调用3：配置服务

在处理工具调用3的配置阶段时，首先需写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。将此阶段视为输入与验证后输出之间的契约。为相关产物命名，明确成功判定标准，并杜绝无声的半完成状态。需为每次调用记录工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试过程将会浪费大量时间。

Resize:
224 → 336

Normalization:
unchanged

工具调用4：评估服务

在处理工具调用第4阶段的评估时，首先需写下相关契约：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。需为每次调用记录工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试代理将陷入无休止的循环，耗费大量时间。

v4.2 + 224px:
AUROC = 0.93

v4.2 + 336px:
AUROC = 0.85

在处理工具调用第4阶段的评估时，首先需写下相关契约：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。

Finding:
The performance degradation is strongly associated with
the preprocessing change from 224px to 336px.

Evidence:
- Model weights unchanged.
- Deployment introduced 336px preprocessing.
- 224px evaluation restores AUROC to 0.93.
- 336px evaluation produces AUROC of 0.85.Recommendation:
Roll back preprocessing to 224px while investigating
why the new preprocessing configuration causes degradation.

15. 上下文工程与RAG

将“上下文工程”这一阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份优秀的示例文本、一个失败案例以及回滚说明。相比庞大的脚本，应优先选择小型且可测试的单元。当某个步骤出现故障时，故障原因应能明确指向某个具体的责任模块，而非复杂的流程链。应将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使另一项也必须重新编写。

Query
 ↓
Retriever
 ↓
Documents
 ↓
LLM

Goal
 ↓
Agent
 ↓
Determine missing context
 ↓
Retrieve / Query / Execute
 ↓
Evaluate results
 ↓
Update state
 ↓
Retrieve again
 ↓
Compress
 ↓
Assemble context
 ↓
LLM
 ↓
Action

16. 上下文工程与特征工程类似

在将“16. 上下文工程”这一阶段视为可度量的对象时，其效果最佳。在扩大范围之前，先记录一份优秀的输出样本、一个失败案例以及回滚说明。把这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，明确成功标准，绝不允许出现悄无声息的半完成状态。保持图结构的状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段，还会在中断后导致无法继续处理。

Raw data
 ↓
Feature engineering
 ↓
Feature selection
 ↓
Model
 ↓
Prediction

Raw information
 ↓
Context retrieval
 ↓
Context filtering
 ↓
Context transformation
 ↓
Context selection
 ↓
LLM
 ↓
Decision

17. 评估上下文质量

Bad retrieval
     ↓
Bad context
     ↓
Bad reasoning
     ↓
Bad action
     ↓
Bad answer

检索质量

上下文质量

推理质量

行动质量

最终任务完成度

Retrieval
   ↓
Context
   ↓
Reasoning
   ↓
Action
   ↓
Outcome

18. 常见错误

错误1：“把所有内容都放入提示词中”

错误2：将向量搜索视为唯一解决方案

错误3：保留无限长的对话历史记录

Recent details
+
Compressed historical state
+
Relevant retrieved information

错误4：将事实与猜测混为一谈

错误5：忽视时间背景

timestamp
version
deployment
experiment
data snapshot
environment

19. 构建首个智能体的实用架构

                 ┌──────────────┐
                 │    User      │
                 └──────┬───────┘
                        ↓
                 ┌──────────────┐
                 │    Agent     │
                 └──────┬───────┘
                        ↓
               ┌─────────────────┐
               │ Context Manager │
               └───────┬─────────┘
                       ↓
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       Search        Database      Tools
          │            │            │
          └────────────┼────────────┘
                       ↓
                 Context Assembly
                       ↓
                      LLM
                       ↓
                     Action
                       ↓
                   Observation
                       ↓
                 Context Update

20. 智能体上下文工程的发展方向

LLM + Tools

LLM
+
Memory
+
Retrieval
+
State
+
Tools
+
Environment
+
Context Management

结论

Prompt Engineering
       ↓
RAG
       ↓
Memory
       ↓
Tool Use
       ↓
State Management
       ↓
Agentic Context Engineering

操作检查清单

全部文章发送简报