对于连续的长期coding任务 面对庞大的codebase 繁多的任务/需求 开发者（我们）在与coding agent的协作过程中如果保证一个良好的context（harness的一部分） 而不是需要我们每次开始一个新任务的时候需要搬运大量重复的context 或者说在处理一些比较复杂的问题 agent给出的方案是全面的

比如一个持续迭代的电商项目，今天让 agent 加退款，明天改优惠券，后天排查库存超卖。你不应该每次都重新解释“订单有哪些状态、库存什么时候扣、哪些接口不能改”。 理想状态是，你只说“处理退款任务”，agent 就能找到相关业务约束、定位调用链、恢复任务进度，最后提交可验证的结果。 要做到这个，我建议把 context 管理做成一个固定工作流，而不只是“把计划存成文档”。 一、把长期知识、任务状态、当前工作上下文分开 长期知识回答：这个系统是什么，为什么这样设计？ 包括业务规则、模块边界、关键数据流、架构决策、开发和验证方式。比如“退款成功后才能恢复库存”“历史订单必须保留成交时的价格”。 任务状态回答：这件事要做到哪里，现在做到哪里？ 每个任务记录目标、非目标、验收条件、依赖任务、已完成部分、阻塞点和下一步。需求多时，用任务索引管理状态和依赖，不要把所有需求都放进一个不断增长的聊天摘要。 当前工作上下文回答：这一轮实际需要看什么？ 只装入当前任务相关的规范、代码片段、测试结果和必要决策，不把整个项目历史搬进来。 关键区别是：长期保存的信息可以很多，但每轮加载的信息应该有选择。 二、入口文件当地图，不当百科全书 可以用 AGENTS.md 这类 agent 能读取的入口，但只放高频、稳定、全局必要的信息： 项目怎么启动和验证。 模块地图在哪里。 业务规则和架构决策去哪里找。 任务开始、执行、结束分别必须做什么。 哪些操作需要人确认。 退款流程的细节放在订单领域文档里，不要让一个修改登录页面的任务也带着整套退款规则。 OpenAI 2026 年 2 月的 harness engineering 实践就是这个思路：他们尝试过巨大的 AGENTS.md，后来改成约 100 行的目录式入口，深层知识按需读取。 注意，不同 coding agent 对入口文件、局部规则的支持不同。不能因为文件存在，就默认它一定会读；要用工具原生规则或启动流程明确接入。 三、让“恢复上下文”成为每次开工的固定动作 新任务启动时，我会要求 agent 先完成这几步： 读取项目入口和任务说明。 检查当前分支、工作区改动、相关提交，避免覆盖已有工作。 按模块地图查找相关规则和实现。 检查依赖任务是否真的完成。 运行必要的基线检查，区分已有问题和本次引入的问题。 然后输出一个简短的“任务理解”： 本次目标是什么。 哪些约束不能破坏。 预计影响哪些模块。 还有哪些事实没有确认。 这样你审核的是它有没有理解对，而不是亲自再搬一遍上下文。 如果自己在做 harness，可以把启动检查做成自动步骤；只是使用现成 coding agent，也可以先用固定规则和可执行脚本实现，不必一上来搭复杂记忆系统。 四、复杂问题先做影响分析，再出方案 “上下文连续”和“方案全面”不是一回事。 就算完整保留聊天记录，agent 也可能只看眼前函数，漏掉其他入口和业务后果。因此复杂任务需要单独的调查阶段。 例如“支持部分退款”，不能只搜到退款接口就开始改。要沿着链路检查： 入口：用户申请、后台操作、支付回调。 状态：多次部分退款、累计退款上限、重复回调。 数据：退款记录、订单金额、库存、优惠券。 副作用：通知、财务对账、异步任务。 兼容性：历史订单、旧客户端、数据库迁移。 验证：正常流程、并发、失败重试、回滚。 要求它在方案里交代“依据哪个实现或规范”“检查过哪些调用方”“哪些地方仍不确定”。没有证据的部分标成假设，而不是写得很自信。 搜索时也不能只靠语义检索：符号引用、调用关系、接口定义、数据库结构和测试都要结合起来。大型仓库还要留意跨服务调用、消息消费者和动态注册，这些不一定能靠某个函数的引用列表找到。 全面不是让它读完所有代码，而是让它覆盖相关影响面，并暴露没有覆盖的地方。 五、交接写状态，不写聊天流水账 每完成一个可验证的小步骤，就更新任务状态，不要等窗口快满或者会话结束才记。 一条有用的交接可以是： 任务：支持部分退款。 已完成：退款记录和金额校验，相关测试通过。 未完成：支付回调幂等、库存恢复。 已确认决策：库存仅在退款成功后恢复。 已排除方案：申请退款时恢复库存，会在支付失败时造成不一致。 验证证据：关联提交和测试结果。 下一步：检查回调重复投递，再补幂等测试。 “我看了几个文件，做了一些修改，后面继续”几乎不能帮助恢复。 聊天摘要适合保留短期探索过程，但已确认的业务规则、决策和任务进度，要写入各自的正式记录。否则摘要反复压缩后，容易把关键约束压没，或者把猜测压成事实。 六、文档必须维护，关键约束必须能执行 最危险的不是没有文档，而是 agent 读到过时文档却认为它是权威。 建议把这些要求纳入完成条件： 改行为，同时更新相关规范。 改接口，同时更新契约和调用示例。 改变方案，标记旧决策已被替代。 完成任务，保留验证证据并归档。 发现文档与实现冲突，明确指出，不能默认代码一定对，也不能默认文档一定对。 能机械检查的规则，尽量变成类型约束、测试、lint 或 CI 检查。 比如“重复退款回调不能重复恢复库存”，文档负责解释，测试负责防止违反。只写进提示词，仍然可能被忽略。 所以最小落地版本不需要很重： 一个简短入口，一份模块地图，每个复杂任务一份带验收条件的计划，再加固定的开工检查、阶段交接和验证流程。 你负责确认目标、关键约束和高风险决策；agent 负责查找、整理、执行和更新。发现重复解释的内容，就把它变成可检索知识；发现重复犯的错误，就把它变成可执行检查。 目标不是让 agent 永远记住所有事情，而是让一个全新的 session 也能低成本重建正确的工作上下文。这样换会话、换模型甚至换 agent，都不用从头带新人。 参考： OpenAI，2026-02-11，仓库知识地图与可执行约束： https://openai.com/index/harness-engineering/ Anthropic，2025-11-26，跨会话进度、增量执行与验证；属于较早的实验实践，不是全面性的保证： https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents