★ FEATURED ARTICLE 1. 1M输出窗口意味着什么从“问一句得一句”到“一句话干完活”干Agent工程这几年我越来越确信一件事上下文窗口就是个双刃剑。以前大家讨论的都是输入窗口能塞多少字比如一次把几十页文档喂进去让模型总结输入长一点顶多多花点钱架构上没什么本质变化。直到我最近用一个代号叫Gemini 4 Argon的模型它的输出窗口直接给到了接近100万token的量级我才真正意识到改变Agent写法的不是输入端而是输出端。这篇东西不是科普什么是Agent而是想聊聊当模型能一口气吐出超大篇幅结果的时候我们这些做工程的人到底该怎么重新设计任务流程。哪些老经验可以直接扔掉哪些新坑会让你凌晨三点爬起来改代码我会把实际遇到的问题和排查过程都摊开来讲。适合正在搞长任务Agent、批量生成、自动报告系统的同学参考特别是那些被小输出窗口憋坏了的场景——比如让Agent一口气处理几百个文件然后汇总成一份完整报告或者让Agent跑完一整个业务流程后输出全量日志和决策依据。这类需求以前靠多次调用加拼接现在有了1M级别的输出窗口路径完全不一样了。1.1 大上下文的分水岭输入窗口和输出窗口不是一回事很多人会把“上下文窗口大”默认理解成“能读得多”但工程上输入和输出的差异非常大。输入窗口决定的是你能给模型多少素材输出窗口决定的却是模型能交付多少成果。一个1M的输入窗口最多说明你可以把一本书喂进去让模型慢慢看但一个1M的输出窗口意味着模型可以自己把一个大型任务从开始做到结束把过程记录、推理步骤、结构化结果、后续建议全部一次性写出来。这两者的工程复杂度完全不是一个量级。输入窗口大你只需要解决“怎么把长文本塞进去不超限”的问题本质是文本切分和拼接输出窗口大你就要处理“模型生成这么长的结果之后程序怎么接住、怎么解析、怎么存储、怎么恢复”的整套难题。我见过不少团队在输入侧玩得很溜embeddings、RAG、上下文压缩都上了但输出侧还停留在“最多几千token然后截断保存”的思维里结果拿到长输出能力之后反而懵了东西是生成了工程管线撑不住。我自己的判断是输出窗口超过100K token之后Agent的设计就已经从“让模型回答一个问题”变成了“让模型执行一个项目”。1M输出窗口更像是把一个临时项目交付物的生产环节整个塞进了模型内部这对工程架构的影响比输入窗口翻倍要大得多。1.2 长输出改变了Agent的三个底层假设第一个被改变的假设是“模型输出应该短小精悍”。以前做Agent提示词里都要写“请简明扼要”“控制在Xtoken内”因为输出一旦拉长截断风险、解析失败风险、成本风险都跟着涨。但有了1M输出窗口这个约束可以放松了。你甚至可以要求模型把每一步工具调用的参数、返回值、中间判断都写进最终输出里形成一份可以被审计的完整工作记录。这在以前是不可想象的——谁舍得拿几万token去记流水账现在舍得。第二个被改变的假设是“记忆必须外部化”。以前长程Agent的记忆方案基本都是向量库加摘要缓存跑几步就把上下文压缩一下再存到外部存储里下次要用了再检索回来。这套方案本身没有错但代价是状态分散、同步复杂、调试困难。1M输出窗口提供了一个很直接的新选项让模型在任务结束时把完整状态、结果和推理链全部输出出来外部系统只需要接住这一份大输出就行记忆的“写入”变得原子化了不再是一堆零散的upsert操作。第三个被改变的假设是“生成是单次瞬时的”。以前只要输出一长大家都会不自觉地把任务拆小因为单次生成长文本容易在后半段质量崩掉。但1M输出窗口让这种拆分的必要性降低了模型有足够的空间在一段连续生成中逐步推进任务甚至在输出的不同段落之间形成内部参照。这对提示词设计的影响很大你不再需要为了“让模型一次只做一件事”而牺牲整体性可以让它在一次生成里完成多阶段工作前提是你的工程管线能撑住。2. 长程Agent工程复盘在1M输出窗口下的架构设计与取舍窗口变大了窗口后面的管线也得跟着换血。我把之前一个典型的K级输出项目搬到1M输出架构上重做了一遍中间踩了不少坑最后沉淀下来的核心就三件事状态怎么管、输出怎么消费、失败怎么恢复。2.1 状态与记忆该省则省该存则存长输出不是让你把什么都往提示词里塞。1M输出窗口解决的是模型能不能写很长模型要写很长前提还是它得有足够信息。所以我的做法是分层全局状态放提示词里中间状态让模型自己写进输出里外部只维护一个精简的清单。具体来说我会用一个全局的state对象保存任务ID、文件清单、目标结构、约束条件这部分序列化之后放进系统提示词。模型在执行过程中每完成一个阶段就在输出里打一个标记块比如:STAGE_START:数据清洗 清洗完成共处理128行剔除空值7处异常值修正3处。 STAGE_END:数据清洗外部系统不解析中间内容只扫描这些标记块把每个阶段的完成状态写进checkpoint表里。这样模型自己不需要维护一个完整的“到哪一步了”的状态变量外部也不需要把模型的所有中间输出都保存下来才能恢复进度。最终需要保存的就是checkpoint表加大输出文件本身。这套设计的关键是从心态上接受“模型输出本身就是一种持久化”。以前我们习惯把模型的输出当成临时计算结果马上转成数据结构存进数据库。但1M输出场景里模型输出的字节量已经接近大型文件的量级你再把它全部灌进内存做结构化解析纯属给自己找麻烦。把它当成一个文件来落盘需要哪段就检索哪段反而更稳。2.2 输出消费不是读全文而是“索引按需取用”这是我觉得最值得分享的一个认知转折。1M输出落盘之后你要面对的是一个几MB甚至更大的文本文件如果你还想用老思路“加载到内存里找JSON解析整个处理完再说”那任何语言跑起来都会很吃力。而且模型长了之后输出格式难免有些不可控一个几MB的文本里如果有一个字段格式不对整个解析就崩了排查起来想死的心都有。我现在的方案是两层。第一层是全文切块索引输出文件按固定段落数或者固定字节数切块每一块记录起始位置、块内包含的阶段标记、大概的字符数写进一个小的索引表。这个索引表可以存在SQLite里查询“第二阶段在哪里”直接走索引不需要扫描整个文件。第二层是按需解析。比如要提取最终的结构化汇总我直接定位到输出文件末尾的汇总区只把最后几千行读出来解析而不是读整个文件。如果要做内容检索我可以在索引基础上跑关键词定位找到命中的块再细致读。整个过程有点类似于数据库的聚簇索引加延迟物化只不过对象从表变成了模型输出文件。这轮重构之后我发现解析耗时从原来的秒级下降到了毫秒级而且出错率大幅下降。核心原则就一句话永远不要让程序同时面对全部输出内容。2.3 断点与幂等长任务必须能重放长输出任务最让人头疼的就是中断。模型生成到一半网络断了或者服务端超时又或者下游解析崩了怎么办1M输出窗口意味着一次任务可能要连续跑几十分钟中断恢复不再是一个可选项而是必须设计进去的兜底能力。我的经验是设计输出分片续传机制。原始接口如果支持流式输出程序就把流式结果按固定大小分批落盘。每落一批就记一个offset这个offset不仅仅是字节位置还包括这批内容里最后一个完整的阶段标记位置。一旦发生中断重试时在提示词里附上“你已经生成到了这个位置的事件”作为恢复点让模型接着往下写。这里要注意模型生成的内容是连续语义不太可能在任意位置无缝续写所以恢复点必须选在语义边界上也就是我们约定的阶段标记之后。恢复时提示词里明确说“上一轮已完成状态B请从状态C开始继续生成剩余阶段”实测下来比直接从断点续写成功率高很多。幂等同样重要。下游的管道消费输出时如果某个阶段处理到一半挂了重启之后不能把已经处理好的阶段又重复处理一遍。我的做法是每个阶段标记块里带一个唯一的run_id加阶段序号处理完成后把这个组合键写入已完成表。重放时先查表命中的块直接跳过不命中才处理这样整个消费链路天然幂等断多少次都能重跑。3. 实操某批量文档分析Agent的1M输出落地理论讲了一堆接下来用一个我自己最近做的模拟项目X来走一遍完整流程。这个项目叫“批量文档审阅与结构化汇总Agent”任务比较典型给它一堆PDF和Word文档它要先逐份读取、做要点摘录、识别风险条款、给出修改建议最后把所有文档的结论汇总成一份总报告。放在以前这活儿至少要拆成几十次调用或者靠一个多Agent框架来回调度。这次我试试只用一个带1M输出窗口的模型让它一口气干完。3.1 任务拆解与Token预算任务拆成五个阶段文档清点与格式校验逐份阅读并输出结构化审阅记录横向对比多个文档中的矛盾条款生成整体风险评估输出最终汇总报告关键决策是不把阶段本身做成多次模型调用而是在提示词里定义好这五个阶段的输出格式要求模型在一次生成中依次完成。每个阶段用我前面提到的STAGE_START和STAGE_END标记包围便于工程解析。Token预算我按两种方式估算。按输入估算假设每个文档平均15000字6份文档就是90000字加上提示词和说明书接近100K token输入量。按输出估算每份文档的审阅记录预计1200到2000 token6份就是12K token左右横向对比和风险分析大概需要3K最终汇总报告按2000 token算总输出大概17K token。这个量级看起来不多但如果把文档数量放大到300份输出量就直奔百万token去了。所以我的模拟项目X先按6份文档做小规模验证架构按1M输出窗口的规模设计保证以后真扔300份文档进来时不返工。3.2 关键配置参数与估算公式我给几个实际用得上的参数配置参考不同模型会有差异但思路通用。温度设为0.2到0.3。长输出任务最怕发散温度太高后半段容易跑偏。最大输出token按任务量动态设置而不是每次都用满100万。小任务硬拉满1M输出一是等太久二是质量不一定有保证。建议设置一个max_output_tokens min(预估输出token * 1.5, 模型上限)的公式留点余量但不铺张。流式输出必须开启。1M输出如果不开流式你就要坐在那儿干等而且中间发生错误你完全不知道只能等超时。开流式之后可以实时看到生成进度也能做分片落盘。超时设置不能按秒算。我算过一笔账假设模型流式输出速度平均每秒30到50个token1M token的生成时长大约在5到9小时之间。所以长任务的客户端超时时间必须设到小时级或者干脆不设超时靠心跳探测。我当时把超时设为3小时跑一个接近100K输出的任务大概70分钟完成时间上是够的。3.3 Python实现流式读流、分片提交、检查点恢复先给一个简化但可直接改的伪代码框架核心处理逻辑都在了。import asyncio import json import re import aiosqlite STAGE_RE re.compile(rSTAGE_START:(\w)(.*?)STAGE_END:\1, re.S) CHUNK_SIZE 2048 # 按字符切分的安全大小 class LongOutputProcessor: def __init__(self, task_id, model_name): self.task_id task_id self.model_name model_name self.partial_text self.chunk_parts [] self.processed_stages set() self.db_path fcheckpoint_{task_id}.db async def init_db(self): async with aiosqlite.connect(self.db_path) as db: await db.execute( CREATE TABLE IF NOT EXISTS stages ( run_id TEXT, stage_name TEXT, done INTEGER, PRIMARY KEY(run_id, stage_name)) ) await db.commit() # 读取上次已完成的阶段 async with db.execute(SELECT stage_name FROM stages WHERE run_id? AND done1, (self.task_id,)) as cursor: async for row in cursor: self.processed_stages.add(row[1]) async def run(self, prompt, run_idNone): await self.init_db() run_id run_id or self.task_id prompt_with_recovery self._inject_recovery_point(prompt, run_id) # 假设 client 是某个支持流式输出的异步客户端 async for delta in client.stream_generate(prompt_with_recovery, modelself.model_name): self.partial_text delta self._parse_and_checkpoint() if FINAL_SUMMARY in self.partial_text: break return self.chunk_parts def _parse_and_checkpoint(self): # 只检查当前累积文本中新增的完整STAGE块 while True: match STAGE_RE.search(self.partial_text) if not match: break stage_name match.group(1) if stage_name in self.processed_stages: self.partial_text self.partial_text[match.end():] continue # 把这个阶段的原文落盘 self._save_chunk(stage_name, match.group(0)) self.processed_stages.add(stage_name) self._mark_done(stage_name) self.partial_text self.partial_text[match.end():] def _inject_recovery_point(self, prompt, run_id): if self.processed_stages: done_list , .join(sorted(self.processed_stages)) prompt ( f\n\n[恢复指令] 本任务之前已经完成如下阶段{done_list}。 f请不要重复生成这些阶段直接从下一个未完成阶段开始。 ) return prompt这里有个细节值得多说两句。我在_parse_and_checkpoint里做的是增量贪心解析每收到一段新的流式文本就尝试从缓存文本里抠出完整的STAGE块。抠出来的块落盘并标记完成剩下的不完整部分留在缓存里继续等下一批数据。这个方案的好处是模型还在继续生成的时候前面阶段的结果已经安全落盘了万一后面断了也不至于前面所有成果全丢。_inject_recovery_point是恢复的核心。它会把已完成阶段名单写回提示词要求模型不要重复生成。实测下来模型基本能遵守这个指令从断点后面的阶段接着输出。但它不是100%靠谱偶尔会重复生成一小段前序内容所以消费端必须保持幂等重复块直接跳过不能报错。3.4 实测数据与成本对照模拟项目X在6份文档的小规模验证里总输入大约92K token总输出约18.5K token单次生成用时约40分钟。同样的任务如果用旧的K级输出方案需要拆成大约25次独立调用每次还要带上下文摘要累计输入会膨胀到150K以上总耗时约55分钟而且工程复杂度高得多——25次调用的失败率叠加起来整体可靠性和可维护性都不如单次长输出。把场景放大到300份文档后我的预估是输入大概需要800K到1M token输出预计在900K到1M token之间已经站在1M输出窗口的边缘。这时候单次生成耗时会达到5小时以上成本也直线上升。所以大规模场景下我并不建议真的把一次生成塞到接近上限而是在架构上支持长输出但实际任务仍然按业务边界拆成若干个“相对长的子任务”每个子任务保持在100K到200K输出这样时间、成本、质量都更可控。成本方面有个简洁估算公式总成本 ≈ 输入token数 × 输入单价 输出token数 × 输出单价。输出窗口越大输出单价的影响越大。以前大家优化成本都盯着输入侧压缩现在长输出场景下输出侧才真正要命。我做个粗算同样的任务量如果把输出从20K放大到200K只要输出单价是输入的3倍以上总成本就会翻好几倍。这也反向要求Agent设计时必须想清楚你真的需要这200K输出吗还是这里面有150K是重复啰嗦的中间推理4. 常见问题与排查实录这几轮实操下来我攒了不少问题有的问题排查过程很曲折挑几个典型的说一说。4.1 输出到一半被截断这是最常遇到也最恶心的。明明设置了很大的输出上限模型生成到半程却停了而且返回结果里没有明确报错看起来像正常结束。第一次遇到我还以为任务跑完了一看内容发现后半段不翼而飞。排查路径是这样的先确认返回信息里的finish_reason字段如果值是length说明触发的是最大token限制而非自然结束。这时候要看是不是上下文里放了太长的示例输出或者任务量估算偏低。我遇到的情况是提示词里给了两个特别长的示例模型模仿示例的冗长风格把预算都花在前面阶段了还没走到最终汇总就被截断。解决方法是动态提高max_output_tokens之外还要做“预算控制提示”。在提示词里明确告诉模型每个阶段预留多少token并给出阶段优先级的降级规则——比如“如果输出接近上限横向对比章节可缩短为表格但最终汇总必须完整”。这种软约束比单纯加大上限管用。4.2 token计数与实际不匹配本地预估token数的时候总是低估尤其是中文内容。曾经出现过我预估18K输出结果实际计费显示25K的情况。这个差异主要来自模型分词器对中文、代码、编号列表的编码方式和我的朴素估算函数不一致。解决办法是两步走。第一步用模型官方同一个tokenizer离线跑一遍样例文档校准自己的估算系数。我在代码里留了一个estimate_tokens(text, coefficient)函数这个系数一开始设为1.2校准之后调到1.45准确度从70%提高到95%以上。第二步所有关键任务都做预算余量不要把预估当成准确值去卡上限永远留30%以上的buffer。4.3 生成超时长生成的超时是个工程坑。曾经有个任务跑了一个多小时客户端不行了服务端其实还在生成。排查下来是默认请求超时设得太短只有60秒或300秒这在长输出任务里完全不可用。我的修复方案是多层超时控制。连接超时短一点30秒就够了连接建立之后WS或者流式API的读超时改成心跳模式不是“等多久没数据就断”而是“超过5分钟没有新数据才断”。同时给整体任务加一个业务层的截止时间比如预估需要4小时就设5小时总截止到点强制停止并走检查点恢复流程。这个分层之后正常生成不会被打断真正卡死的时候又能兜底。4.4 输出质量衰减开头深刻结尾敷衍这是我觉得最难解决的问题。模型在超长输出任务里前20%内容逻辑清晰、细节到位越到后面越糊分析深度明显下降甚至会出现复述前面内容当新内容的凑字数行为。我复盘之后认为原因有两个一是提示词里阶段顺序不够合理把需要深度思考的风险评估放得太靠后模型生成到那里已经有些疲劳二是中间没有任何干预机制模型在长上下文上越往后越容易出现注意力的远端遗忘效应。针对性地做了三个调整。调整阶段优先级把最烧脑的部分放到中前段后段放相对格式化的汇总。在阶段之间插入简短的“小节衔接指令”让模型在生成完一个阶段后先写两句小结再进入下一个阶段相当于给自己做了一次版本刷新。有条件的话给模型加“中途反思”环节利用长输出窗口的特性让它每隔一段时间主动检查之前输出的内容是否有遗漏然后补充修正。这招在特别长的任务里最管用相当于把一次性长跑改成了带折返点的马拉松。4.5 长输出内容检索困难任务跑完了输出文件好几MB人工想找某一条结论翻半天。这个问题一开始我没太在意直到需要审计某个决策依据时才意识到长输出如果没有一个好的检索机制价值会大打折扣。后来我加了一个后处理脚本扫描输出文件里的阶段标记块自动生成摘要索引每个阶段块提取首句和末句作为摘要、记录字符偏移、识别所有引用的文档名。摘要索引存成一个Markdown目录文件放在输出文件开头。这样不管人工查看还是下游程序消费都能很快定位到目标区域。实际用下来这个索引对调试帮助极大很多问题翻索引比翻全文快十倍。5. 工程边界的本质与下一步扩展拿到1M输出窗口之后我反而更清楚一个道理工程边界从来不在窗口数字本身而在模型输出的可靠性和可消费性。5.1 边界不是窗口大小而是“单次生成无法收敛”长输出做得越多越发现模型和大规模输出之间存在一个内在矛盾。模型生成是前向的、渐进的它没有能力在生成了80%内容之后回到开头大规模修改前期已经落定的事实判断。一旦某个关键结论在后面发现错了它只能在后续文本里打补丁、做修订整个输出就变得臃肿且自相矛盾。这种“收敛性”问题不是靠增大窗口能解决的。所以我的工程判断是1M输出窗口适合的场景是那些“过程大致可预见、结果结构化、错误允许在后续修订”的任务比如批量文档审阅、日志汇总、代码库迁移说明、全量测试报告。它不适合的场景是对生成结果有严格一致性要求、或者需要多轮反覆修正的创作型任务。这类任务强行塞进长输出里反而会产出大量需要返工的内容。5.2 混合架构长输出加外部记忆双通道我现在的最终方案不是唯长输出论而是长输出和外部记忆混合使用。具体分工是长输出负责“结果生产”尽量在一次生成中完成有业务边界的完整交付物落盘之后作为权威记录。外部记忆负责“过程协同”工具调用结果、临时计算、需要跨任务复用的实体信息都通过外部存储实时同步模型不需要把这些过程信息全部写进输出里只需要在输出中引用外部记录的ID。这个混合架构的好处是模型输出不再是唯一的信息载体哪怕输出被截断或者质量不佳外部记忆里还有过程数据可以补救。同时输出文件也不是孤立的文本它和外部记录通过ID互相联动形成一个可审计、可回溯、可局部重跑的系统。我在实际项目中已经把输入侧RAG、输出侧长文档、外部侧checkpoint表全部串起来了。刚开始觉得有点重跑通之后才发现这其实是长输出能力真正落地的最稳路径——模型负责把活干完工程负责把活干出来的东西管好。最后分享一个我个人的体会别被1M这个数字带着跑盲目追求“一次生成越久越厉害”是没有意义的。真正有价值的是你想清楚一次长输出要完成哪个业务闭环然后让工程架构配合这个闭环去设计。窗口是模型给的但边界是你自己定的。先想清楚边界在哪再决定要不要把窗口用满这才是长程Agent工程的正解。
阅读完成 · 觉得有帮助？
