从 agent、workflow 到上下文工程：关于认知对齐与长期协作的实践思考

最近看了很多有关agent和上下文工程的文章也写一点自己在工作中的理解。在讨论agent和workflow之前首先需要对齐一个概念二者最大的区别不在于是否使用大模型而在于决策权到底由谁主导。workflow更像是一条预先设计好的pipeline。代码负责控制流程llm被嵌入其中承担判断、分类、选择、信息抽取、正则补全、文本生成等局部能力。它的核心是确定性结构加上局部智能。agent则更强调由模型主导下一步行动。它不仅回答问题还会根据目标、上下文和当前状态自主选择skill、工具、资料路径和执行顺序。相比workflowagent的自由度更高也更依赖上下文质量。最基础的上下文工程是让模型清楚知道自己要做什么、有什么输入、应该产出什么、哪些约束不能违反。再进一步它关心的是模型在每一个环节里是否真正理解了任务、角色、边界和判断标准。这就引出了一个更关键的概念认知对齐。所谓认知对齐不只是我告诉模型一段背景。更重要的是我要确认模型是否真的理解了这段背景并且能在后续行动中稳定地使用它。在实际开发过程中发现很多失败不是模型能力不够而是模型以为自己懂了但其实理解产生了偏差。这也是为什么grill-me这类skill最近很有价值。它的意义不只是让模型多问几个问题而是通过连续追问暴露一些隐藏的假设、模糊概念和未定义边界。有时候就像和llm在玩海龟汤而我在承担主持人..所以很多时候我在思考一个问题模型的注意力在哪里这是一个很有意思的话题尤其是之前做深度学习的时候魔改各种注意力模块。但在上下文工程中注意力一直是被忽略的一个点。在实际使用中首段输入和高优先级上下文往往非常重要。它们会强烈影响模型后续的注意力分配、任务理解和输出风格。如果一开始的方向、角色或目标设定产生偏差后面的输出就会沿着错误的方向继续展开。另外随着对话变长模型就会开始关注一些我们认为可有可无的点。行业目前更多的称呼这种现象为上下文腐败。一次对话变长之后早期信息会被稀释新信息会不断覆盖旧判断临时决策会变成默认前提模型也可能把中间产物误认为最终共识。对于长期项目来说这种腐烂会越来越明显。因此长期构建项目几乎不可避免地依赖本地文档的积累。文档不是为了给模型看也是为了给人自己看。它可以是项目认知的外部记忆也可以是人和新模型之间用来快速对齐的媒介。但文档本身也不是一劳永逸的。从贝叶斯更新的角度看人的认知会随着新信息进入而变化。今天认为重要的边界明天可能变成噪音一开始写下的设计原则后来可能需要被修正。因此早期和模型交互形成的文档也应该随着项目演进不断更新。这是件很困难的事情。人会遗忘会偷懒会把阶段性判断误认为长期认知。模型则会受上下文、版本、提示方式和工具环境影响能力表现并不恒定。长期项目里这种双重漂移会不断积累。更麻烦的是大模型的默认倾向往往是兼容性和覆盖面。它会倾向于把方案设计得更通用、更完整、更保险有时也会因此引入不必要的抽象和复杂度。短期看这是稳妥长期看就可能变成技术债。很多所谓技术债并不是某一次模型写错了代码而是无数次看起来合理的过度设计堆积出来的。所以在使用模型构建长期项目时人的认知带宽依然是最重要的资源。模型可以加速生成、检索、改写和实现但不能替代人的判断、取舍和记忆。越是复杂项目越不能把总结这件事完全交给模型。更好的方式是自己多写多记多思考多改。可以借助模型生成初稿、整理结构、补充遗漏但最终的笔记应该由人来吸收、筛选和重写。因为写笔记不是文档劳动而是认知压缩。只有经过自己改写的内容才真正进入自己的判断的体系里。这些笔记会不断迭代。最开始它可能只是零散记录后来会变成项目词汇表、架构原则、决策记录、失败案例、工具使用约定等。到最后这份笔记本身就会成为最优秀的上下文。最后必须意识到一个点大模型不是百分百正确的。当模型给出一个判断时尤其是涉及架构、事实、依赖、性能、安全或长期维护成本时不要只看它说得是否流畅。更应该想想它参考了什么资料它的思考、推理路径是什么它的结论适用于什么边界我觉得在大部分情况下不要让你的llm变成豆包。最后的最后我认为设计一个良好的agent或者workflow是在每一个环节里都能明确谁在决策、依据是什么、上下文是否可靠、输出是否被验证。亦或者说是把和llm交互看成一个工程化的东西而在这过程中人和模型在长期协作中需要保持同一个认知状态。