你的AI代理上下文需要一个开发生命周期这两年我一直在折腾AI代理AI Agent这类东西从最早用单轮Prompt拼一个能聊天的壳到后来真正把代理接到业务系统里做自动化任务最大的感受是大部分代理项目不是死在模型能力上而是死在上下文管理上。上下文一旦乱七八糟再强的模型也会给你一本正经地胡说八道。这个问题的本质在于大多数开发者还在把上下文当成聊天记录的堆叠觉得把历史消息一股脑塞给模型就算完事。但真正到了生产环境上下文的大小、结构、新鲜度、优先级全部会直接影响代理的输出质量。我自己的项目里就踩过不少坑上下文太长导致模型忽略关键指令上下文太短导致代理失忆上下文里混入了上一个任务的残留数据导致结果完全跑偏。后来我逐渐意识到AI代理的上下文必须像软件代码一样有一套完整的开发生命周期来管理——从需求分析、设计、实现、测试到部署、监控和维护。这听起来有点重但当你开始用这个思路去建设上下文很多诡异的问题会自然消失。这篇文章就把我整套的实践方法、代码示例和踩坑记录分享出来希望对正在做AI代理开发的朋友有用。1. 先搞清楚上下文到底为什么成了AI代理的命门1.1 上下文不是聊天记录是代理的工作记忆很多人对上下文的理解就是把以前说过的话再发给模型。这个理解在简单聊天场景下够用但在AI代理场景下远远不够。AI代理的本质是一个能自主决策、调用工具、执行多步骤任务的程序。它不像聊天机器人那样只需要回应上一句话而是要在一个长任务中持续保持对目标、约束、中间结果、外部状态的感知。这套感知系统就是上下文。你可以把上下文理解为代理的工作记忆——一个人类程序员在写代码时脑子里同时装着需求文档、当前文件的代码结构、刚刚重构过的函数签名、以及编译器报错信息。AI代理也一样它需要同时记住用户要什么现在做到哪一步了有哪些历史决策外部系统返回了什么数据。如果这套工作记忆没有良好的组织结构代理就会表现出典型的人工智障行为重复执行已经完成的操作、忽略用户明确提出的限制条件、在错误的假设上继续推理。这些问题表面上看是模型能力不足实际上绝大多数是上下文供给出了问题。1.2 大模型能力边界幻觉、上下文窗口、温度之间的三角关系要管好上下文必须先理解模型的三个核心边界这三者不是独立的它们相互拉扯共同决定代理的行为表现。第一是幻觉。幻觉的根源是模型在信息不足时会脑补最合理的答案。当上下文里缺失关键事实模型不会说我不知道而是会编一个看起来合理的答案。这就是为什么幻觉问题不能只靠换更强的模型解决更要靠上下文工程去补足信息密度。第二是上下文窗口。模型能接收的Token数量是有限的Claude、GPT、Gemini各有各的窗口上限但如果真把窗口塞满代价不只是费用还有注意力稀释。我在实测中发现当上下文超过一定长度后模型对中段内容的关注度会明显下降重要的指令如果埋在长文本中间大概率会被忽略。这不是玄学Transformer的注意力机制天然偏好开头和结尾的内容也就是所谓的Lost in the Middle现象。第三是温度Temperature。温度控制的是输出的随机性。很多人在调代理时忽略了一个关键点即便温度设得很低只要上下文内部有矛盾或歧义模型依然可能在不同的正确性之间摇摆。温度解决不了信息冲突的问题它只放大或缩小信息的呈现力度。这三者的关系可以这样理解幻觉是信息不足时模型硬编上下文窗口是信息太多时模型看不全温度是信息矛盾时模型怎么选。上下文管理的目标就是让模型在有限窗口内拿到足够、干净、无冲突的信息。1.3 上下文漂移AI代理最常见的失忆事故在代理跑长任务时我遇到最多的问题就是上下文漂移。什么叫漂移就是随着对话轮数和任务步骤增加代理对最初目标和核心约束的记忆越来越模糊行为逐渐偏离用户本意。举个我实际碰到的例子。我有一个自动化调研代理用户让它调研新能源汽车充电桩市场输出一份包含竞争格局的报告。代理在执行过程中调用了搜索工具、打开了几十个网页、做了好几轮总结。跑到第20轮时它开始把充电桩技术标准和充电桩运营模式的内容混在一起最后报告里甚至出现了充电桩的电池寿命这种明显概念错乱的表述。原因就是早期的核心目标已经被海量的中间结果淹没了模型只记得最近在聊什么忘了最初要什么。这就是上下文漂移。它不一定是模型笨而是上下文的管理方式有缺陷。如果从一开始就把目标约束输出格式要求放在上下文的显眼位置并且定期增强Refresh这些核心信息漂移是可以被压制的。这个定期增强的动作其实就是生命周期管理中的维护环节。2. 上下文工程把上下文当作产品来建设2.1 上下文数据流图的分解从原始信息到有效上下文要管理上下文第一步是画清楚上下文的数据流。我看过不少团队的代码上下文就是在代码里东拼西凑这段加个系统提示那段拼个历史记录最后再塞几个函数返回值。这种屎山式上下文的问题在于你根本不知道哪些信息在哪个环节进了模型。我自己做上下文工程时会先把上下文数据流图拆成四个层级原始数据层数据库记录、API响应、网页抓取内容、用户输入、工具执行结果。这些数据格式各异、噪声大不能直接进模型。加工处理层对原始数据做清洗、截断、摘要、结构化提取。这个层级负责把原材料变成半成品。上下文组装层按当前任务的需要从半成品中选择合适的信息组合成模型实际看到的Prompt。模型消费层模型读取组装好的上下文产生推理和输出。输出的结果又会作为新的数据回流到原始数据层。这四个层级的核心思想是不要让模型直接面对原始数据海洋而是通过中间的加工和组装让模型每次只看到当前这一步最需要的信息。我见过有人把整个数据库的schema全文塞进上下文就为了让模型理解数据结构结果上下文被无关字段占满真正重要的数据反而没地方放了。正确的做法是根据当前操作的表和字段动态生成一份精简的schema描述。2.2 结构化上下文的设计思路分层与摘要分层算是上下文结构设计里最实用的方法没有之一。我把上下文分为四个优先级不同的层第一层是系统层包含代理的角色设定、能力边界、输出格式规范、安全规则。这一层相当于操作系统的内核始终存在不容篡改。系统层的信息必须精炼每一条都要有存在的理由。第二层是任务层包含当前任务的最终目标、约束条件、交付物要求。这一层相当于项目立项书在任务开始时就固定下来后续不随对话轮次变化。如果任务中途有调整需要显式地更新任务层内容而不是靠模型从对话里自行推断。第三层是状态层包含任务执行的中间状态已完成步骤、当前正在进行的操作、待办事项、已获取的关键结论。这一层相当于程序员手边的便签本需要频繁更新但要保持精简及时清理过时信息。第四层是记忆层包含跨任务的历史经验、用户偏好、之前任务中提炼的可复用结论。这一层是长期记忆需要单独存储而不是每次都塞进上下文。和分层配套的机制是摘要。摘要的作用是让上下文瘦身。比如一个代理读了20个网页每个网页2千字直接塞给模型就是4万字窗口直接爆掉。合理的做法是先用一个小模型或规则脚本把每个网页压缩成200字的要点列表再把要点列表喂给主模型。这样既保留了关键信息又把上下文控制在可管理的范围内。2.3 用FastAPI做上下文服务的实践参考当代理的上下文管理逻辑变复杂之后我强烈建议把它从业务代码里抽离出来单独做成一个上下文服务。我自己的实现里用的是FastAPI来搭这个服务。选择FastAPI的原因很直接异步支持好可以并行处理多个上下文请求类型标注清晰接口文档自动生成团队协作时沟通成本低轻量不需要像Django那样搭一套完整架子。我简单演示一下这个服务的核心结构。首先定义一个上下文对象模型from pydantic import BaseModel from typing import List, Dict, Optional class ContextSegment(BaseModel): segment_id: str layer: str # system / task / state / memory content: str priority: int # 数值越大优先级越高 expires_at: Optional[int] None # 过期时间戳用于自动清理 class ContextPack(BaseModel): task_id: str segments: List[ContextSegment] current_step: str 然后提供一个组装上下文的接口接收任务ID返回拼装好的Prompt字符串from fastapi import FastAPI, HTTPException from contextlib import asynccontextmanager import redis.asyncio as redis app FastAPI() redis_client redis.from_url(redis://localhost:6379/0) def get_context_pack(task_id: str) - ContextPack: # 从Redis中取出该任务的上下文分段列表 raw redis_client.get(fctx:{task_id}) if not raw: raise HTTPException(status_code404, detailcontext not found) return ContextPack.model_validate_json(raw) app.post(/contexts/{task_id}/compose) async def compose_context(task_id: str, max_tokens: int 8000): pack await get_context_pack(task_id) # 按优先级排序再按窗口预算截断 ordered sorted(pack.segments, keylambda s: s.priority, reverseTrue) budget 0 selected [] for seg in ordered: seg_tokens estimate_tokens(seg.content) if budget seg_tokens max_tokens: continue selected.append(f{seg.layer}\n{seg.content}/{seg.layer}) budget seg_tokens return {prompt: \n\n.join(selected)}这段代码的核心逻辑是先按优先级排序分段再根据Token预算决定哪些上下文进模型。estimate_tokens是一个估算Token数的函数可以用tiktoken或transformers的tokenizer做近似计算。把上下文做成独立服务的好处是业务代码不用关心上下文怎么拼只负责调用接口上下文的调优可以在不影响业务代码的情况下独立迭代测试时可以直接对上下文服务做单元测试验证不同优先级组合下的输出效果。一套成熟系统的上下文服务最终会演变成一个完整的上下文中心负责所有代理任务的上下文供给。3. 为上下文建立开发生命周期六个阶段的落地方法3.1 阶段一需求分析——界定代理必须知道什么很多代理做不好根因在需求阶段就没想清楚模型到底需要什么信息。写Prompt之前先回答三个问题当前这个任务模型完成每一步操作必须知道哪些事实这些事实从哪里来哪些事实是有时效性的我习惯用上下文最小集这个概念来约束需求分析。所谓最小集就是让模型能够正确完成任务所必需的最小信息集合不多不少。比如做一个根据邮件自动创建日历事件的代理最小集包括邮件原文中的时间信息、活动标题、参与人邮箱列表、用户的时区偏好。而邮件的完整签名档、历史往来记录、公司的邮件排版规范统统不在最小集内。如果你发现自己列出的上下文需求超过10项一定要警惕。这说明任务本身可能太复杂或者你在用上下文掩盖糟糕的任务拆解。一个设计良好的代理单个步骤的上下文最小集应该控制在3到5项。3.2 阶段二上下文设计——写一份上下文设计文档需求明确之后动笔写代码之前先写上下文设计文档。这个文档不需要很长但必须包含以下内容上下文分层方案、每层包含的字段和来源、各字段的更新频率、令牌预算分配、冲突处理规则。令牌预算分配是我觉得最有价值的一个设计动作。假设你的模型上下文窗口是128K但你不能真用满我一般留出20%到30%给模型的输出和临时推理空间实际给上下文用的大概是80%左右。这80%里系统层占10%、任务层占15%、状态层占35%、记忆层占20%剩下20%留给动态插入的工具返回结果。上下文设计文档还有一个作用它是后续测试和评审的依据。没有这个文档你没法判断模型出错是因为上下文缺失、上下文错误还是模型本身的推理问题。有了文档你可以逐条对照快速定位是哪一层的信息出了问题。3.3 阶段三实现与注入——代码层面的上下文组装实现阶段的核心问题是上下文如何在正确的时机、以正确的形式注入到模型中。这里的时机很关键。不是每轮对话都需要完整上下文。我把注入策略分为三种全量注入任务刚开始时系统层、任务层、状态层、记忆层全部加载让模型建立起完整的任务图景。差异注入任务执行过程中只加载发生变化的部分。比如代理刚执行完一个搜索只需要把搜索结果摘要追加到状态层不需要重新发送全部历史。按需注入模型即将调用某个工具时只注入与该工具相关的上下文。比如调用发送邮件工具前注入收件人、主题、正文模板调用查询数据库工具前注入表结构和查询限制。在实现时我会封装一个ContextManager类统一管理注入逻辑。它内部维护当前任务的分层上下文状态每次与模型交互前按照当前步骤从各层抽取必要信息组装成Prompt并记录本次实际注入的内容方便之后审计。还有一个容易踩的坑工具返回值的注入。很多代理框架会把工具返回值原样塞给模型但工具返回值往往是结构化JSON字段冗长、包含大量无关元数据。正确的做法是在工具调用后加一层结果提取用一个小函数或提示词把JSON压缩成自然语言要点再注入上下文。3.4 阶段四测试与评估——如何度量上下文质量上下文的质量不是靠感觉判断的必须有一套可量化的测试方法。我给上下文设计了四类测试指标召回率模型中是否包含了完成任务所需的关键事实测试方法是设计一系列信息探测问题把上下文交给模型看它能答对多少。精准率上下文里是否混入了无关或过时信息测试方法是人为制造上下文污染比如插入另一个任务的数据看模型是否会被误导。注意力命中率真正重要的信息是否放在了模型容易注意到的位置测试方法是把关键指令放在上下文不同位置对比模型的表现差异。代谢率上下文更新是否及时测试方法是模拟状态变化看代理下一次执行时能否感知到变化。实际操作中我常用的是黄金案例回放法。把过去项目中10到20个成功案例保存下来包括当时的任务描述、上下文内容和理想输出。每次修改上下文组织逻辑后跑一遍黄金案例集看有多少案例输出质量下降。这个做法相当于回归测试能有效防止上下文改动带来的副作用。3.5 阶段五部署与监控——生产环境中的上下文体检上下文上了生产环境必须建立监控。不是监控模型的响应时间而是监控上下文本身的质量状态。我主要监控四类指标第一类是上下文窗口占用率。如果长期超过90%说明上下文虚胖需要加强摘要或压缩策略。如果长期低于30%说明注入内容不足模型可能处于饥饿状态幻觉风险升高。第二类是上下文更新失败率。代理在运行中向状态层写入新信息如果写入失败比如Redis连接异常、JSON解析报错模型就会基于过期信息继续推理。第三类是工具结果注入延迟。每次工具返回值从生成到注入模型的耗时理论上应该在毫秒级。延迟过高意味着模型可能在用旧数据做决策。第四类是用户反馈关联分析。把用户对输出结果的点赞/点踩和该次请求的上下文特征关联起来看哪些上下文模式更容易导致差评。这个分析能反哺上下文设计的迭代方向。监控实现上我推荐用结构化的JSON日志记录每次请求的上下文摘要包括各层段的Token数、优先级、来源标识然后接入类似PrometheusGrafana或云厂商的日志平台做聚合展示。3.6 阶段六维护与迭代——上下文的版本管理上下文和代码一样会持续演进。昨天设计的上下文结构今天可能就不满足新需求了。因此必须给上下文加上版本管理。我建议给每套上下文设计方案定义一个版本号像V1、V1.1、V2这种。每次改动都要写明变更记录改了哪一层、加了什么字段、删了什么内容、为什么改。这样当新版本出现问题时可以快速回滚到旧版本。我在项目里就是这么做的每个任务的上下文包都会带上context_version字段监控平台按版本分组统计数据。有一次我升级了任务层的描述模板结果发现所有任务的完成率下降了12%通过版本对比定位到是模板里新增的一句请尽可能详细地描述你的思考过程导致模型把大量Token花在自我分析上挤占了实际推理空间。回滚后立刻恢复正常。上下文的维护还不只是版本问题还包括陈旧信息的定期清理。比如状态层里记录的中间结果如果已经用于生成最终产出就可以标记为已消费在新的上下文中不再加载。这个动作我称之为上下文垃圾回收虽然听起来很基础但真在现场能坚持做的团队不多。4. 实操实录一个基于本地模型的AI代理助手上下文改造4.1 本地模型与云端模型的上下文差异近期很多朋友开始关注AI代理助手加本地模型的组合我也实际做过几个本地化方案。本地模型和云端大模型在上下文处理上有个核心差异本地模型的上下文窗口通常更小常见的7B、13B模型窗口在4K到32K之间而且对长上下文的注意力衰减更明显幻觉问题往往比大模型更严重。这意味着如果用本地模型做代理上下文的精选要求更高。你不能像用GPT-4那样把一堆参考资料直接扔进去必须提前做大量的摘要和结构化工作。我改造过的一个调研助手原来在云端模型下可以接受完整网页原文换成本地模型后必须改成先提取要点再组装摘要否则模型几乎都会在长文本下半段丢失关键信息。这个改造反而促使我把上下文生命周期管理做得更严格。因为本地模型没有大窗口兜底每一步的上下文都必须精准命中需求任何冗余都是浪费。这算是一个因祸得福的收获。4.2 执行上下文的抽象与实现在代理系统里执行上下文Execution Context比对话历史更贴近工程实际。它是代理在运行到任意时间点时程序内存中的全套状态——不仅仅是对话消息还包括当前步骤编号、已完成操作列表、变量绑定关系、工具调用栈、待处理队列等。我实现执行上下文的方式是引入一个统一的AgentState对象。这个对象是一个JSON结构贯穿整个代理生命周期每个工具函数、每个业务模块都能读写它。核心代码如下class AgentState: 代理执行状态的统一容器 def __init__(self, task_id: str): self.task_id task_id self.step 0 self.history: List[dict] [] self.variables: dict {} self.completed_steps: List[str] [] self.pending_queue: List[str] [] self.metadata: dict {} def snapshot(self) - dict: 生成当前状态快照用于持久化和审计 return { task_id: self.task_id, step: self.step, history: self.history[-20:], # 只保留最近20轮 variables: self.variables, completed_steps: self.completed_steps, pending_queue: self.pending_queue, } def restore(self, data: dict): 从快照恢复状态用于任务中断后继续执行 self.step data[step] self.history data[history] self.variables data[variables] self.completed_steps data[completed_steps] self.pending_queue data[pending_queue]这段代码的要义在于variables字段是动态键值对允许工具函数往里面写中间结果history只保留最近20轮避免无限增长snapshot方法随时可以序列化整个状态这样任务意外中断后能从最近的快照恢复而不是让代理失忆重来。执行上下文与模型上下文在这里实现了分离AgentState是程序层面的真实状态模型上下文是喂给模型的信息子集。每次与模型交互时我们从AgentState中抽取、转换、摘要生成当轮Prompt。程序状态和模型输入不再混为一谈这是我从混乱走向可控的关键一步。4.3 超长上下文的截断、压缩与遗忘策略当任务真的需要大量信息时窗口再大也不够用。这时必须有一套组合策略来处理超长上下文。我在本地模型实战中用的策略是截断压缩遗忘三重组合。截断是最后的手段简单粗暴地从最早的历史开始丢弃。要注意的是截断不能无差别进行。我开发了truncate_context函数它会先保护系统层和任务层然后从状态层和记忆层中按优先级从低到高丢弃内容。这个函数的核心逻辑是import tiktoken def estimate_tokens(text: str) - int: enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text)) def truncate_context(segments: list, max_tokens: int) - list: 按优先级截断上下文低优先级先被淘汰 protected [s for s in segments if s.layer in (system, task)] expendable [s for s in segments if s.layer not in (system, task)] expendable.sort(keylambda s: s.priority) used sum(estimate_tokens(s.content) for s in protected) result protected.copy() for seg in expendable: seg_tokens estimate_tokens(seg.content) if used seg_tokens max_tokens: result.append(seg) used seg_tokens else: # 超出部分截断文本本身保留头部 remaining max_tokens - used if remaining 100: result.append(ContextSegment( segment_idseg.segment_id, layerseg.layer, contentseg.content[:remaining * 3], # 粗略按字符截断 priorityseg.priority )) break return result压缩是真正的杀手锏。我会用一个小型本地模型比如Qwen-1.5B或更小的专门做内容压缩把一段500Token的网页内容压缩成80Token的信息密集摘要。这样既保留了语义又大幅降低了Token占用。压缩的质量直接影响下游输出因此压缩提示词要非常明确比如提取所有事实性数据、关键结论和行动项忽略修饰性语言。遗忘策略则对应那个问题Claude超过上下文限制会怎么样——如果不主动遗忘就会被强制遗忘。与其让模型在超限时被动丢失信息不如由我们自己主动决定遗忘什么。我的遗忘规则很简单超过3轮未引用的中间结果标记为冷数据从主上下文中移出如果任务后续需要再通过检索从长期存储中拉回。这个冷热分离的思路让代理在主上下文里始终只保留热数据冷数据放在外部存储中按需取用。5. 常见问题与排查技巧实录5.1 上下文被截断模型答非所问现象代理执行到一半突然开始回答一些与任务完全无关的内容或者输出明显不完整的结论。排查后发现模型收到的上下文被系统自动截断了后半段内容可能是任务约束或关键工具结果被切掉模型在信息残缺的状态下强行作答。排查思路先看上下文的Token占用曲线。如果某次请求Token数刚好达到模型窗口上限十有八九是截断导致的。再看日志里的原始上下文内容确认被截断的位置在哪。我遇到过不少次负责组装上下文的代码把最新工具结果追加在文本末尾而上下文拼接的顺序恰好让模型先读旧内容后读新内容一旦截断最新、最关键的信息反而最先被丢弃。解决方法是调整拼接顺序把当前步骤需要的关键信息放在上下文开头或结尾的高注意力区域把历史背景放在中间。同时在代码里显式地给每个分段分配Token预算而不是依赖最后加进来的内容自动保留。5.2 上下文污染旧任务数据串台现象代理在处理新任务时突然提到了上一个任务的细节甚至用上一个任务的数据来回答当前问题。这是典型的上下文污染。我第一次遇到时很困惑因为每次新任务都重新清空了对话历史。后来发现问题出在共享的全局变量上。我的AgentState里有一个全局variables字典工具函数往里面写入数据时用了固定键名比如result两个任务各自写入的result互相覆盖代理取到了上一个任务的残留数据。修复方式有二第一任务级的变量必须加上task_id前缀或使用独立的命名空间第二在任务启动时对AgentState做一次完整的状态体检清除所有不归属于当前任务的字段。我还加了一条防御规则当上下文组装时如果发现variables中的数据产生时间早于任务启动时间直接丢弃并报警。5.3 幻觉高发上下文密度不足现象代理频繁编造数据、虚构来源、给出不存在的结论。很多时候不是模型想编而是上下文里根本没有足够的事实锚点。我之前调试一个竞品分析代理时它输出的报告里出现了一个竞争对手产品的具体定价看起来很专业但完全是编的。排查后发现任务层只告诉模型分析竞品但没有给它注入任何具体的竞品数据。模型在信息真空中只能靠训练记忆和想象补全。解决思路是上下文密度原则在上下文里给到模型的每一个关键论断都必须附带事实依据。比如竞品A的定价为X元数据来源官网2024年Q3价格页要比竞品A价格较低这种模糊描述有效得多。实际操作中我会在工具返回结构化数据后强制要求数据摘要必须包含来源字段并在组装上下文时把来源一并写入。5.4 排查工具与调试建议做上下文调试没有好工具会很痛苦。我推荐一套组合拳日志先行每个请求都要打印完整的上下文内容按层分段这样出问题时能一眼看出模型看到了什么。上下文快照对比用前面说的上下文设计文档逐层对比应该有什么和实际有什么。最小复现实验把有问题的任务抽象成一个最小可复现的Prompt手动削减或增加上下文逼近问题边界。香草对照用最朴素的上下文只放任务描述不加任何历史跑一遍同样的请求对比输出差异。如果朴素版本反而更好说明你的上下文组织在帮倒忙。调试本地模型还有一个特殊技巧因为本地模型的推理成本低我会用批量轰炸的方式做实验——同一个任务生成10个版本的上下文变体同时跑对比输出差异。这比在云端接口上逐个试要快得多也更容易暴露上下文结构中真正的问题点。6. 写在最后的几个实操心得做AI代理上下文生命周期管理这一年多我在实际踩坑中总结出几条可能跟主流观点不太一样的经验。第一不要迷信长上下文窗口。就算未来模型窗口扩大到1M Token上下文工程依然有意义。因为核心瓶颈从来不是装不装得下而是模型在长文本中能不能保持稳定的注意力。窗口再大信息密度不足导致的幻觉问题依然存在。把有限的窗口用于放置精确的、结构化的、高价值的信息永远比一股脑塞满更有用。第二上下文的生命周期不是一套形式化的流程文档而是切切实实的工程动作。需求分析帮你厘清信息边界设计阶段帮你分配Token预算实现阶段帮你建立组装机制测试阶段帮你度量质量监控阶段帮你在生产环境发现问题维护阶段帮你持续迭代。这根链条上每一环都省不了省了后面就会加倍偿还。第三如果你刚开始做AI代理别急着写复杂的上下文管理框架。先用最简单的方式跑通一个端到端任务然后用我前面提到的上下文最小集原则一层层往里加信息。每加一层跑一遍回归测试观察输出是否变好。变好了就留下没变好就删掉。这个加减法的过程就是上下文工程的日常。实际上AI代理的发展还在非常早期上下文管理也没有银弹。但把它当成一个有生命周期的系统来建设至少能让你在遇到问题时知道从哪个环节入手去排查而不是对着黑盒模型干瞪眼。希望这篇文章能帮你少走一些我走过的弯路。