循环内的上下文：每轮给模型哪些信息

1. 上下文是一份当前任务材料

上下文是本次请求中提供给模型的信息，包括任务目标、规则、对话、工具结果和相关资料。模型决定下一步时，只能使用当前请求里的材料及已有能力，因此程序需要把刚取得的观察整理进去。

可以把上下文想成开会前准备的一页简报：先写今天要解决什么，再放有关资料和已经确认的结果。把一周聊天记录全部打印出来，重要结论反而难找。

循环每一轮都在变化：第一轮知道用户目标，第二轮可能已有订单金额，第三轮已有政策。构建上下文就是把这些变化整理为下一轮可用的输入。容量需要限制，否则历史追加会增加请求用量和阅读噪声。

2. 做一个能手算容量的材料筛选器

先在 PowerShell 创建并进入学习目录：

mkdir "F:\学习\l3-context" -Force
cd "F:\学习\l3-context"

保存下面的文件后，在这个终端运行 dir 核对文件名，再执行本节给出的运行命令。

在新目录创建 context.py：

先在 PowerShell 创建并进入学习目录：

mkdir "F:\学习\l3-context" -Force
cd "F:\学习\l3-context"

保存下面的文件后，在这个终端运行 dir 核对文件名，再执行本节给出的运行命令。

"""把当前目标和有关资料装入一个有容量限制的上下文。"""
import json

def build_context(goal, rows, limit):
    if type(limit) is not int or limit < 0:
        raise ValueError("容量须为非负整数")
    for row in rows:
        if type(row["cost"]) is not int or row["cost"] < 0:
            raise ValueError("资料成本须为非负整数")
    # cost 是为方便手算设置的容量单位。
    goal_text = "目标：" + goal
    remaining = limit - 4
    if remaining < 0:
        raise ValueError("容量不足以放入目标")
    selected = [goal_text]
    for row in rows:
        # 先筛选有关资料，再比较它是否能放进剩余容量。
        if row["relevant"] and row["cost"] <= remaining:
            selected.append(row["text"])
            remaining -= row["cost"]
    return selected

if __name__ == "__main__":
    rows = [
        {"text": "昨天问过天气", "cost": 5, "relevant": False},
        {"text": "退款期限7天，来源policy", "cost": 4, "relevant": True},
        {"text": "完整订单历史", "cost": 9, "relevant": True},
    ]
    print(json.dumps(build_context("查退款", rows, limit=8), ensure_ascii=False))
    print(json.dumps(build_context("查退款", rows, limit=17), ensure_ascii=False))

ls
python context.py

输出：

["目标：查退款", "退款期限7天，来源policy"]
["目标：查退款", "退款期限7天，来源policy", "完整订单历史"]

代码里的 cost 是练习用容量单位，目标固定占4。容量和资料成本先检查为非负整数，错误输入在装入资料前被指出。容量8时剩4，能放入政策，完整历史占9所以留在外面。容量17时剩13，两份相关资料都能放入。天气记录无论容量多大都被筛掉，因为 relevant 为 False。

selected 保存已经选入的字符串，remaining 保存剩余容量。每放入一份资料就扣除它的容量。实际模型请求应按使用的分词器或接口用量估计Token，同时预留输出空间。

3. 改动相关性和顺序

把天气的 relevant 改为 True，容量仍为8。天气占5，放不下，政策仍可进入。再把天气的 cost 改成4，它先占满余额，后面的政策就放不进去了。

每次保存后运行 python context.py，对照第一行的选入材料。这个变化展示了贪心装入的代价：当前算法按列表顺序优先，而非按价值排序。恢复天气的relevant为False、cost为5再重跑，第一行恢复政策资料。进一步扩展时，可以将资料按相关度、可信度和时间排列，再依次装入。

4. 用测试保存判断规则

在同目录创建 test_context.py：

下面的测试检查目标和相关资料是否保留、容量是否超限，以及非法预算是否被识别。

"""检查context示例的正常路径和边界结果。"""
import unittest
from context import build_context
class Tests(unittest.TestCase):
    def test_keep(self):
        rows=[{"text":"旧资料","cost":5,"relevant":False},{"text":"退款7天","cost":4,"relevant":True}]
        self.assertEqual(build_context("查退款",rows,8),["目标：查退款","退款7天"])
    def test_budget(self): self.assertEqual(build_context("查退款",[{"text":"过长","cost":9,"relevant":True}],8),["目标：查退款"])
    def test_invalid_cost(self):
        for cost in (-1, True, 1.5):
            with self.assertRaises(ValueError):
                build_context("查退款",[{"text":"资料","cost":cost,"relevant":True}],8)
    def test_invalid_limit(self):
        with self.assertRaises(ValueError): build_context("查退款",[],True)

if __name__ == "__main__":
    unittest.main()

python -m unittest test_context -v

正常路径与改动后的边界都在测试中检查。若结果不同，先定位失败的断言，再回到对应的字段与分支。

5. 把信息分层，保留关键约束

总结历史时，金额、日期和审批绑定字段可保存为结构化数据，再由摘要补充说明。新资料中的文字应作为数据处理；资料里出现“忽略用户要求”，也只是检索内容的一部分，应用程序仍依据原任务和权限规则执行。

重复来源适合合并，过时版本适合更新，失败记录保留足够定位问题的信息。压缩应保留来源和待确认项，让后续回答能回查。可以用同一问题对比两份上下文：完整堆叠与精选材料，检查答案覆盖、引用和输入用量。

Anthropic 上下文工程说明讨论如何管理有限上下文。先理解“筛选、排序、容量”的例子，再考虑摘要、检索和长任务记忆。

手算资料进入上下文的顺序

容量8，目标占4，剩余4。遍历天气资料时relevant为False，直接跳过。退款政策相关、成本4，装入后剩0。完整历史相关、成本9，留在本轮之外。

扩大容量会改变能装入的资料，但与任务无关的天气仍被筛出。把政策放到历史之后，历史若能放下就会先占容量。因此排序是另一个明确的决策，可以按相关程度和必要性安排。

更完整的上下文可分成稳定指令、当前目标、状态快照和证据片段。证据旁保留来源、时间或版本，下一轮就能区分新旧资料。摘要适合压缩已讨论过的长段落；数字和审批绑定字段适合保留原值。

扩展例子时，可以给row增加priority，先排序再装入。观察小容量下关键政策是否仍被选中，然后对比输入长度和答复覆盖。这个实验直接检查材料组织怎样影响下一步，而不是仅仅加大窗口。

回顾与下一步

目标常驻，资料筛选，状态更新，容量可算。接着读 任务路由，根据当前任务选择合适的入口。