本文探讨了如何通过改进 Agent 的任务管理机制来克服上下文窗口限制提升大模型在复杂任务中的表现。文章提出了使用“todo_write”工具来记录和更新任务列表确保模型在执行过程中始终了解当前进度和下一步计划。通过维护一个实时更新的任务状态列表并定期提醒模型更新状态有效解决了任务规划被稀释的问题。该方法简单易行仅需少量代码调整即可显著提升 Agent 的规划能力特别适合需要处理多步骤任务的场景。给 Agent 派一个 10 步的重构任务。它干得挺好改了前两个文件第三步跑测试发现两个 case 挂了。从这一刻起它的注意力全在测试报错上了。最初说好的把所有 Python 文件改成 snake_case 命名这件事悄悄消失了。等它跑完一轮你发现它修好了测试但有一半文件根本没碰。这不是模型的问题是上下文窗口的物理性质决定的。一、上下文越长系统提示越没用Agent 每调用一次工具工具的返回结果就追加进 messages。任务进行到第 5 步messages 里已经塞满了 bash 输出、文件内容、编辑结果。而系统提示SYSTEM从第一条就固定在那里越来越靠后。模型在生成下一步的时候对上下文里靠近当前位置的 token 权重更高——这是 Transformer 注意力机制本身的特性不是 bug是设计。所以第 1 步写的任务计划到第 5 步时影响力已经大幅衰减。对话越长越严重。一个需要 15 步才能完成的重构做完前三步第 4-15 步的计划就基本上被稀释掉了。Agent 进入即兴发挥状态哪里有输出就往哪里走。二、解法不是让模型更聪明是把计划钉在消息历史里想清楚问题的本质计划消失是因为计划写在系统提示里而系统提示随着对话深入影响力衰减。那解法就是让计划本身成为 messages 里的内容而且每一步执行后都能更新它让最新状态始终出现在上下文的靠近当前位置的地方。这就是 todo_write 工具的核心逻辑。它不执行任何操作不读文件不跑命令只做一件事接收一个带状态的任务列表保存在内存里同时把当前状态返回给模型作为工具结果。每次调用 todo_write模型就等于在 messages 里写了一条新的进度快照。三、实现细节︱任务列表的数据结构每个任务是一个 dict有两个字段{ content: Add type hints to all functions, status: in_progress # pending | in_progress | completed }三种状态对应任务的生命周期待开始 → 进行中 → 已完成。全局维护一个列表CURRENT_TODOS: list[dict] []注意这是进程内存退出就没了。这个设计是有意为之的——同一个对话内共享状态不同会话各自独立不需要持久化。︱run_todo_write 的实现def run_todo_write(todos: list) - str: global CURRENT_TODOS todos, error _normalize_todos(todos) if error: return error CURRENT_TODOS todos lines [\n/033[33m## Current Tasks/033[0m] for t in CURRENT_TODOS: icon { pending: , in_progress: /033[36m▸/033[0m, completed: /033[32m✓/033[0m }[t[status]] lines.append(f [{icon}] {t[content]}) print(\n.join(lines)) return fUpdated {len(CURRENT_TODOS)} tasks这里有个细节值得注意函数里的 print 是给终端看的让人知道 Agent 在规划什么。但 return 的字符串才是真正重要的——它作为工具结果追加进 messages模型下一轮生成时会读到它。_normalize_todos 负责做输入校验因为模型有时会把参数序列化成 JSON 字符串而不是直接传列表需要兼容两种格式def _normalize_todos(todos): if isinstance(todos, str): try: todos json.loads(todos) except json.JSONDecodeError: try: todos ast.literal_eval(todos) except (SyntaxError, ValueError): return None, Error: todos must be a list or JSON array string if not isinstance(todos, list): return None, Error: todos must be a list for i, t in enumerate(todos): if not isinstance(t, dict): return None, fError: todos[{i}] must be an object if content not in t or status not in t: return None, fError: todos[{i}] missing content or status if t[status] not in (pending, in_progress, completed): return None, fError: todos[{i}] has invalid status {t[status]} return todos, None︱接入 dispatch 系统上一个版本已经有一套 TOOL_HANDLERS 分发机制工具调用进来根据 tool_call.function.name 找对应的处理函数。新增 todo_write 只需要两步第一步把工具定义加进 TOOLS 列表{ type: function, function: { name: todo_write, description: Create and manage a task list for your current coding session., parameters: { type: object, properties: { todos: { type: array, items: { type: object, properties: { content: {type: string}, status: { type: string, enum: [pending, in_progress, completed] } }, required: [content, status] } } } } } }第二步加进 dispatch mapTOOL_HANDLERS[todo_write] run_todo_write分发逻辑不用改。todo_write 来了TOOL_HANDLERS.get(“todo_write”) 找到函数参数解析调用返回结果。和 bash、read_file 完全一样的路径。︱系统提示加一句话SYSTEM ( fYou are a coding agent at {WORKDIR}. Before starting any multi-step task, use todo_write to plan your steps. Update status as you go. )这句话的作用是建立模型的默认行为模式收到任务 → 先列计划 → 再动手。没有这句模型不会主动想到用 todo_write因为它不知道这个工具的预期使用时机。有个实际问题模型执行中途容易忘了更新 TODO 状态。任务开始时列了计划做了三四个工具调用后停下来更新 todo_write 这个意识会被稀释掉。解法是在 Agent 循环里加一个计数器rounds_since_todo 0 def agent_loop(messages:list): global rounds_since_todo while True: # 超过 3 轮没调 todo_write注入提醒 if rounds_since_todo 3 and messages: messages.append({ role: user, content: reminderUpdate your todos./reminder }) rounds_since_todo 0 response client.chat.completions.create(...) messages.append(response.choices[0].message) if not response.choices[0].message.tool_calls: # 模型停止工具调用触发 Stop 钩子后退出 ... return rounds_since_todo 1 # 每轮工具调用递增 for tool_call in response.choices[0].message.tool_calls: ... # 调用 todo_write 时重置计数器 if tool_call.function.name todo_write: rounds_since_todo 0 ...rounds_since_todo 是全局的每轮工具调用递增。todo_write 被调用时归零。连续三轮没调就往 messages 里塞一条 role: user 的提醒消息。这里用 role: user 而不是 role: system 是有考虑的很多模型对 user 消息的响应优先级高于 system注入到对话流里比修改系统提示效果更稳定。四、Agent 执行的典型流程一个正常工作的流程是这样的用户发送任务“重构这个文件加类型注解、docstring再补一个 main guard”Agent 第一次工具调用todo_write列出 3 个 pending 的步骤调用 read_file 读文件内容调用 edit_file 加类型注解同时更新 todo_write第一步改成 in_progress完成后再次调用 todo_write第一步改成 completed第二步改成 in_progress继续执行直到所有步骤变成 completed模型停止工具调用输出总结每次调用 todo_write当前的完整任务列表就出现在 messages 里。模型在后续每一轮生成时都能看到现在在做哪步、还有哪些没做——这才是这个工具真正有效的原因。todo_write 不让 Agent 能做更多事情。它在不改变 Agent 执行能力的前提下增加了结构化规划和进度追踪能力。两者的区别很重要。执行能力是Agent 能调用什么工具规划能力是Agent 知道自己在做什么、下一步该做什么。上下文稀释导致的问题根源在规划能力的丧失不在执行能力。所以加一个不执行任何操作的工具专门用来保持规划状态就能解决问题。这个设计思路在更复杂的系统里会一再出现不是给 Agent 加更强的工具而是给 Agent 加更好的状态管理。五、相比上一版本改动极小上一版本引入了 Hooks 系统四个事件UserPromptSubmit、PreToolUse、PostToolUse、Stop、一个注册表、一个触发函数。这套机制这一版一行没动。这一版的变更点只有四个新增 run_todo_write() 和 _normalize_todos() 两个函数TOOLS 列表里加一条 todo_write 的定义TOOL_HANDLERS 里加一行 dispatch 映射agent_loop 里加一个 rounds_since_todo 计数器和 reminder 注入SYSTEM 提示改了一句话。其他全部不变。加一个工具改一行提示加一个计数器——Agent 从做着做着就偏变成先列计划再执行做完打钩忘了提醒你。六、往深处看任务系统的两个版本如果看真实的 Claude Code 源码会发现任务系统有两套实现并存。V1也就是这一版实现的原型一个工具数据在进程内存的 AppState 里维护退出清空。交互简单适合单次会话内的任务追踪。V2后面会讲到四个独立工具Create/Get/Update/List、文件持久化存在 Claude 配置目录的 tasks/{taskListId}/{taskId}.json、blockedBy 字段支持依赖图、proper-lockfile 做并发安全。两套系统由 isTodoV2Enabled() 控制切换交互式会话默认启用 V2非交互式会话通过 SDK 调用默认使用 V1。设置环境变量 CLAUDE_CODE_ENABLE_TASKS 可以在非交互式下强制开启 V2。注意源码里有一个容易误读的注释“Force-enable tasks in non-interactive mode”描述的是这个环境变量路径的用途不是 isTodoV2Enabled() 默认分支的返回值语义。读源码的时候要区分清楚。V1 和 V2 还有一个细节差异V1 没有 activeForm 字段V2 有用来给 UI 的 spinner 展示正在做什么。终端版本不需要这个字段因为 print 直接输出就够了。七、跑起来看什么运行起来之后重点观察几件事收到任务后第一次工具调用是不是 todo_write如果模型直接开始调 bash 或 read_file说明系统提示的引导没生效需要调整提示措辞。TODO 列了几步和任务的实际复杂度匹配吗过少说明模型对任务理解不够细过多说明模型在过度拆解增加了不必要的上下文占用。pending → in_progress → completed 的状态流转有没有发生如果所有任务直接跳过 in_progress说明模型在批量完成后才更新状态中间过程没有追踪遇到中断就会丢失进度。reminder 在什么时候触发如果一个简单任务就触发了 reminder说明任务分解可能太细每步之间频繁切换工具导致 todo 更新间隔拉长。这几个观察点加在一起基本能判断 Agent 的规划行为是否符合预期。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取