原文链接AI 小老六Agent 编程真正拉开差距的地方已经不只是“会不会写提示词”。更要紧的是上下文怎么进入任务任务怎么自我验证长程执行怎么不断修正最后这些经验又怎么被团队和下一轮 Agent 继续使用。如果只把 Agent 当成个人窗口里的助手它确实能提速。但它越好用问题也越明显判断、踩坑、取舍、验证方式全都锁在一个人的会话里。下一位同事看不到下一个 Agent 也拿不到。要让 Agent 从“帮我干活”变成“帮团队积累能力”需要一条完整的 Context Loop。Context Intake先问清楚而不是先写 Spec图从需求澄清、工程反馈到团队 Wiki 的 Context Loop 总览很多团队最开始会把希望放在Spec Coding上先写 Proposal、Design、Tasks再让 Agent 照着做。这个做法看起来稳定其实有两个硬伤。第一Spec 很快过期。代码仓库在变、接口在变、同事的提交也在变。Agent 如果拿着几天前的文档继续执行里面的假设可能已经失效。对工程任务来说代码和真实运行结果才是 source of truth。第二Spec 容易制造一种错觉文档写完了交付就会自动发生。可 Agent 真正卡住的地方经常是状态应该放哪里、已有接口能不能复用、失败后怎么恢复、验收标准到底算不算通过。这些问题不是靠更长的模板解决的。更有效的入口是 Grilling。它不是让 Agent 先产出一大篇设计再在里面找缺口而是在写文档之前就把问题问穿这个需求到底解决什么问题哪些边界绝对不能碰有没有现成模块可以复用什么状态算完成什么状态只能算“看起来能跑”如果失败用户现场怎么保住产物不需要厚。通常一份很薄的Context ADR就够目标、验收标准、关键决策、已排除方案。施工路径不必写死留给 Agent 在代码和反馈里自己调整。Context over Control别把 Agent 关进选项题给上下文不等于控制每一步。很多 Agent 会习惯性地抛选择题A 方案、B 方案、C 方案。低风险分支这样做没问题但方向性判断一旦被压成选项错误假设就混进来了。比如“登录态过期怎么处理”答案不该只是“跳转登录页 / 弹窗 / 静默刷新”。真正重要的上下文可能是不能丢用户正在编辑的内容token 过期、权限不足、网络失败要分开处理刷新失败后要保留现场还要能恢复。这个判断塞不进 ABC。可以在AGENTS.md或CLAUDE.md里写一条简单规则涉及产品方向、架构边界、数据一致性、权限和恢复策略时不要只给选择题。 先用文字说明你的判断、假设和不确定点再和人讨论。低风险实现细节可以给选项。这条规则的核心不是礼貌而是避免上下文被 Agent 的选项提前裁剪。另一个很实用的输入技巧是语音。打字会让人天然压缩信息很多背景、担心和反例写着写着就省掉了。语音输入反而容易把真实动机和边界条件讲出来再让输入法或 Agent 整理成结构化文本。对 Agent 来说这些“碎碎念”经常比一份工整 PRD 更有价值。Prototype Handoff体验问题先做出来看交互体验、状态流转、信息架构这类问题靠文字讨论到一定程度就会失真。最省时间的办法不是继续聊而是让 Agent 做一个低保真 prototype。更稳的做法是把探索会话和主会话隔离图主会话、探索会话和人工反馈之间的 prototype handoff 链路隔离的好处很直接。主会话不被试错过程污染探索会话也不用背完整历史包袱。体验完把结论写回主线即可。对复杂交互来说这比在一个长会话里反复描述“感觉不对”要可靠。HarnessLoop 能跑多远取决于反馈多硬图测试、CI、视觉回归等硬反馈让 Agent 能围绕目标持续修正上下文聊清楚后还得让 Agent 知道自己做得对不对。这里的 Harness 不是抽象概念就是测试、CI、lint、类型检查、截图回归、溢出检测这些工程反馈。提示词和 Skill 有用但它们是概率性的。上下文一长模型可能忘注意力一分散规则可能被覆盖。lint 和 test 不一样它们每次都会触发。更重要的是报错本身就是最精准的提示哪一行错了为什么错怎么改全部在反馈里。如果某条提示词被反复写、反复强调通常说明它不该继续待在提示词里而该沉到 Harness。反馈层Agent 能闭环到哪里典型做法编译检查至少保证项目能构建tsc、go test、构建脚本Lint / 类型规则把重复性规范变成硬约束ESLint、自定义 rule、静态检查单元测试验证业务逻辑没有跑偏关键分支、边界条件、错误恢复集成测试验证模块之间能连起来API、状态流、权限链路视觉回归验证页面没有被改坏Playwright 截图对比、溢出检测有多少 Harness就能放心让 Agent Loop 到多远。只有编译检查就让它 Loop 到编译通过有单测就让它 Loop 到逻辑正确有视觉回归才敢让它自己调布局和动效。Goal Loop让 Agent 围绕目标自己转起来复杂任务通常不是一次修改就结束。实现、测试、失败、修复、再测试这本来就是一个循环。如果每一步都要人来盯Agent 再快也会被人卡住。一个可执行的/goal指令需要三件事目标、退出条件、验证方式。/goal让移动端页面在 iPhone 14 尺寸下不出现横向溢出。 退出条件 - Playwright 截图对比通过- 控制台无 layout 相关错误 - 修改不影响桌面端关键布局 验证方式 - 运行 npm run test:visual - 如果失败阅读失败截图和 diff继续修到通过这类 Loop 的边界要清楚。它适合有明确反馈的小任务不适合一开始就丢一个巨大目标。没有 Harness 的 Loop 只是自动化试错烧 token不一定产出稳定结果。自动化任务也可以按这个思路设计。比如每天早上扫描昨天的 CI 失败能修的自动修修不了的汇总每周整理一次团队 Wiki把看板、文档和讨论里的新知识炼化进去。关键仍然是反馈闭环不是定时任务本身。Long Task Runtime长程任务别塞进一个会话短任务可以在一个会话里 Loop。任务一长问题会一起冒出来目标漂移、反复尝试同一个错误方案、测试反馈在上下文压缩后丢失、token 开销快速膨胀。根因不是窗口不够大而是单个会话承载了太多职责。处理长程任务有三种常见手段。手段解决的问题注意点大需求拆解控制单次 Loop 的复杂度子需求要能独立验收不能碎成无意义任务运行时编排并行推进互不依赖的工作用 git worktree、Sub Agent或脚本编排隔离上下文状态外置防止会话压缩后丢掉关键决策用薄 Context ADR 记录目标、边界、已排除方案Sub Agent 编排时主会话最容易犯的错是忍不住抢活。Worker 沉默一会儿Main Agent 就想 kill 掉重来或者自己接手继续做。更好的协议是Main Agent 只定义目标、输入、验收标准和返回格式Worker 不报告 blocked、不要求人介入、不明确失败就不要打断。状态外置也很关键。传统 Spec 一旦太厚重新加载时会占掉上下文窗口里最宝贵的区域。薄 Context 文件只记录高密度信息目标、验收、架构决策、排除方案。其余细节让 Agent 从代码里读。能从代码推导出来的不必再写一遍。Team Loop把 Agent 的工作现场公开出来个人 Agent 跑顺之后团队层面的瓶颈会变成可见性。需求讨论过什么Agent 问过什么哪个方案被排除为什么最后选了这个实现这些信息如果只在个人会话里存在就会变成知识孤岛。公开工作现场的思路是把 Agent 放进团队已经在用的地方群聊、话题、会议、看板。需求还没定型时就让产品、设计、研发、QA 和 Agent 在同一个公开空间里打磨。Agent 如果连着代码仓库、历史文档和设计稿它可能比任何单个人的上下文都完整。它问出的“仓库里是不是已有类似接口”或“这个状态和现有权限模型冲突”能提前暴露问题。会议也一样。逐字稿不是给人逐行读的而是给 Agent 读的。智能摘要会抹掉争论、犹豫、未决分歧恰好这些细节对后续判断最有价值。录制和逐字稿如果能进入后续检索链路下一轮 Agent 就不用从“大家当时为什么这么定”开始猜。看板是另一个入口。让 Agent 像人一样出现在任务面板上有身份、有进度、有审计能领取任务、汇报 blocker、留下决策过程。这个问题的重点不是“Agent 怎么互相聊天”而是团队如何管理 Agent 的工作状态。共享 Agent 还会带来权限隔离问题。多个人在群里 同一个 Agent它到底用谁的身份访问谁的仓库权限授权缓存会不会串比较稳的做法是做 per-user 目录、工具 wrapper 注入身份环境变量再加授权 preflight先确认用户身份再确认工具鉴权最后确认资源权限。正常路径下不能让用户 A 的授权被用户 B 的任务误用。LLM Wiki让下一轮 Agent 不从零开始图原始素材、编译层 Wiki 和治理规则共同支撑下一轮 Agent 召回公开现场解决的是“过程可见”LLM Wiki 解决的是“经验可复用”。它不是资料仓库也不是把所有聊天记录塞进向量库。更合理的结构是三层raw/sources/ 原始素材不可变用来追溯事实来源 wiki/ 编译层沉淀概念、对比、经验和综合判断 governance/ 规则层放 purpose、schema、AGENTS 等约束为什么不用 Agent 自带的长期记忆自动积累的 memory 时间久了会变脏噪声多、来源不清、适用范围不明Agent 还可能把它当成可靠前提。Wiki 的价值在于经过筛选和维护能追溯来源也能标注过期和矛盾。为什么不只靠 RAG群聊、飞书文档、Bug 单、Git history 分散在各处现场检索容易召回碎片。某条群消息可能是错的正确结论藏在另一个 Bug 单评论里。Wiki 是提前做过整理、交叉验证和时间线对齐的结果Agent 读到的不是某个人某一刻的观点而是一份经过清理的判断。维护也不该靠每次任务结束时顺手写。那会侵占主任务注意力而且当前会话视野有限容易沉淀错东西。更稳的是独立自动化每天或每周扫描看板 issue、历史会话、文档和代码提交把有持久价值的内容更新进 Wiki。已有页面就补强不要动不动新建重复条目。分层规则可以很简单AGENTS.md放每次必须遵守、违反就会出错的规则。wiki/放有持久价值、但不是每次都要加载的经验。临时 Context 任务完成后可以删不要让短期状态污染长期知识。代码能表达的不重复写进 Wiki。消费方式也有两种。Agent 开工前自动查 Wiki按 index 和 schema 找相关页面不全量加载。人想了解某个主题时也可以直接让 Agent 查 Wiki甚至现场生成一个 HTML 讲解页。几百个 Markdown 文件靠人翻没意义靠 Agent 导航才是它该有的用法。Eval召回有没有用要能测​Wiki 不是越厚越好​。它有没有用最终要看 Agent 的表现有没有变好。可以从 10 到 20 个历史 issue 做私有评测集优先选那些“第一次失败是因为缺少历史知识”的 case。对比两组执行不开 Wiki 召回、开启 Wiki 召回。观测三个点就够Agent 有没有主动去查 Wiki。查到的内容是不是对的。最终结果有没有变好。小样本足够看早期信号。比起追求一套大而全的评测系统先把“历史知识有没有帮到当前任务”测出来更重要。一条更现实的 Agent 工程链路Context Loop 可以压成一句话需求靠共同打磨质量靠 Harness交付靠 Loop经验靠 Wiki 复利。这不是某个工具或提示词能单独解决的事。Grilling 负责把目标问清楚Harness 负责把反馈变硬Loop 负责让 Agent 自己修到通过Runtime 编排负责撑住长程任务公开现场和 Wiki 负责把个人会话里的知识释放出来。Agent 越能干人越不该把时间花在盯每一步执行上。人的价值会更集中在判断什么值得做什么不能碰什么才算做对。这个判断可以被 Grilling 引出被 Harness 验证被 Wiki 传下去但判断本身还得有人负责。推荐阅读Agent 工程化新底座用 CLI 契约层打通 HTTP 接口与业务能力AI 研发共生架构别再问 AI 会不会替代程序员啦AI Coding 不只靠 PromptAgent 工程闭环如何接入 DevOpsSkillOpt 架构拆解把 Skill 文本当参数用执行轨迹训练 AgentMulti-Agent 执行闭环AI Coding 真正进生产要靠模型分工和工程护栏