周末读了下 Devin 团队的文章， 我大体认同作者把 “Context Engineering（上下文工程）” 提升为构建长期可靠 Agent 的核心，尤其是「共享上下文」和「避免隐性决策冲突」这两条原则。 在实践里，很多质量问题或者bug 确实最终都能追溯到上下文缺失或冲突。但我对文中某些结论的“强度”有不同看法，主要在下面三点： 1. 多 Agent 架构并非天生“错方向”，关键在共享介质与调度策略 2. 「压缩摘要模型」并非唯一的长上下文方案 3. 「行动隐含决策」≠ 必须禁止所有并行 单独再细讲一下
一、多 Agent 架构并非天生“错方向”，关键在共享介质与调度策略： 1. 集中式黑板 / 内存总线：让所有 Agent 的读写都围绕同一段结构化「黑板」进行（可持久化到 KV 或向量索引）；决策仍可并行，但信息单源。我们在业务中使 LangGraph，节点间共享“Graph State”即黑板，每个节点读取→写入。 2.
二、「压缩摘要模型」并非唯一的长上下文方案 作者提出用专门的 LLM 做摘要压缩——这确实管用，但也带来信息丢失、摘要偏差的风险。可并行或替代的思路： 1. 向量索引+检索，大家很熟悉，就不解释了 2. Sliding Window + Chunk Attn，常规思路，实现相对简单，但是长期记忆不行 3. 树状 / DAG
三、「行动隐含决策」≠ 必须禁止所有并行 作者用 Flappy Bird 例子说明并行会产出风格冲突。我赞同并行前需统一决策，但并不意味着完全序列化才能可靠。比如两个前端一起做一个项目，并不是会出现风格冲突的问题，因为有 Figma 看着呢！类比到 AI Agent，可以先生成 “规范/契约”（视觉风格表、接口
周末读了下 Devin 团队的文章，
我大体认同作者把 “Context Engineering（上下文工程）” 提升为构建长期可靠 Agent 的核心，尤其是「共享上下文」和「避免隐性决策冲突」这两条原则。
在实践里，很多质量问题或者bug 确实最终都能追溯到上下文缺失或冲突。但我对文中某些结论的“强度”有不同看法，主要在下面三点：
1. 多 Agent 架构并非天生“错方向”，关键在共享介质与调度策略
2. 「压缩摘要模型」并非唯一的长上下文方案
3. 「行动隐含决策」≠ 必须禁止所有并行
单独再细讲一下一、多 Agent 架构并非天生“错方向”，关键在共享介质与调度策略：
1. 集中式黑板 / 内存总线：让所有 Agent 的读写都围绕同一段结构化「黑板」进行（可持久化到 KV 或向量索引）；决策仍可并行，但信息单源。我们在业务中使 LangGraph，节点间共享“Graph State”即黑板，每个节点读取→写入。
2.二、「压缩摘要模型」并非唯一的长上下文方案
作者提出用专门的 LLM 做摘要压缩——这确实管用，但也带来信息丢失、摘要偏差的风险。可并行或替代的思路：
1. 向量索引+检索，大家很熟悉，就不解释了
2. Sliding Window + Chunk Attn，常规思路，实现相对简单，但是长期记忆不行
3. 树状 / DAG三、「行动隐含决策」≠ 必须禁止所有并行
作者用 Flappy Bird 例子说明并行会产出风格冲突。我赞同并行前需统一决策，但并不意味着完全序列化才能可靠。比如两个前端一起做一个项目，并不是会出现风格冲突的问题，因为有 Figma 看着呢！类比到 AI Agent，可以先生成 “规范/契约”（视觉风格表、接口