摘要：在构建智能Agent时，很多团队常常将回答不准确、信息混乱等问题归咎于模型能力不足。然而，真正的根源可能在于上下文管理不善。
在构建智能Agent时，很多团队常常将回答不准确、信息混乱等问题归咎于模型能力不足。然而，真正的根源可能在于上下文管理不善。
很多团队在做Agent的时候，可能会出现回答飘、信息混乱、工具频繁误调用——体验烂，效果差。通常简单把问题归咎于模型能力或参数不够。
但可能过错怪了模型。真正的元问题往往在于上下文管理。当信息在长任务中被错误地、冗余地或混乱地写入模型窗口，哪怕最强的模型也会表现糟糕。
下面用「 Injob AI 写简历」这个实践，从问题、成因、案例到可落地的工程策略，给出一套系统化的策略方案。
上下文 = 模型在一次调用中能“看到”的所有 token（包括历史对话、状态、工具返回等）。当这些信息被“污染”、“过载”或“混淆”时，Agent 的判断、检索和工具调用都会失准。
在长任务执行中，常见的三大核心挑战：
1、上下文污染：不相干或错误信息混入当前会话/状态，导致后续生成被“脏数据”污染。
以简历为例：用户上传了三个历史版本的简历和多个岗位信息，Agent/大模型 在重写“项目经历”时把不同版本的描述混合，出现自相矛盾或夸大事实的条目。
2、上下文过载：对话／文档极长（如 >10万 token）时，模型性能骤降，重要信息被“稀释”或丢失。
以简历为例：长期与用户交互记录、历史面试反馈、职位 JD、行业模板全部堆在一起，模型无法稳定找到“当前目标职位的关键约束”，导致简历不能准确对齐 JD。
3、工具混淆：当系统可用工具很多（例如几十个以上）且没有严格的工具注册与选择机制时，工具调用的准确率和效率会显著下滑。
可落地的四个策略（Write / Select / Compress / Isolate）
1）写入策略（Write）——把“重要的中间结果”保存到对的地方目标：避免把所有中间产物一股脑塞进主对话窗口。
实践要点：
动态加载：为每条长任务维护独立的草稿文档，关键状态写入短期记忆中，而不是混合在上下文。在Injob实践中，每次简历生成独立draft（id+meta），每次对话时主动更新，保证agent知道当前最新的简历是什么。Checkpoint：阶段性把稳定结果写成checkpoint（例如JSON+元数据），并只把checkpoint的摘要放入主上下文。2）选择策略（Select）——只装载最关键的信息目标：突破“全量加载”的思维，用检索/重排把关键信息动态装入模型窗口。
实践要点：
重要性评分：为历史片段计算importance=f(recency,mention_count,task_relevance)，只保留top-K。分层检索：先用向量检索拿到候选，再用轻量语义打分器重排（Reranker）。时间与角色加权：越新的信息权重越高。3）压缩策略（Compress）——在失效前把历史“摘要化”目标：当上下文占用逼近窗口上限时，自动压缩、丢地部分旧历史，保持信息密度。
实践要点：
触发阈值：例如当token使用率接近窗口的90–95%时触发压缩（可配参数化）。多层摘要：先做抽取式保真摘要（保留关键片段），再做生成式压缩（把同类历史合并成一段精简描述）。可验证压缩：保留原段落指针和“恢复索引”，以便必要时回溯并展开（tradeoff的可控性）。InjobAI写简历中：用户 20 次迭代后会话超长，系统把前 10 次迭代压缩成“摘要 + 关键信念列表”，适当丢弃部分不重要信息。
4）隔离策略（Isolate）——架构层面的“沙箱化”与工具治理目标：用架构把不同职责分开、把工具能力明确定界，防止交叉污染与误调用。
Injob AI实践要点：
三元架构：对话（Conversation）— 计划（Plan）— 执行（Execute）
多Agent沙箱（多进程/多服务）：每个子任务（规划、执行、验证）运行在独立运作的agent，只通过结构化事件总线交换必要数据。共享部分记忆，不是全部的上下文，保证每个agent关注核心的事情。核心想法：把整个“写简历”流程拆成多个角色（对话agent/计划agent/执行agent/校验agent）并在沙箱中彼此隔离，避免数据流互相污染。Manus、smolagents等系统说明了多-agent与沙箱执行的可行性与挑战。要把 Agent 从“偶尔好用”变成“可预测可靠”，工程化的上下文管理比盲目换模型更加划算。建议按短中长期清单逐步推进：先做选择与写入的低成本改造，再引入压缩与隔离。
本文由 @易俊源 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
来源：人人都是产品经理一点号