共享上下文之后，AI 会怎样改变软件架构？
内容提要
文章从GUI Agent的操作树出发，探讨共享上下文如何改变信息交接成本。作者指出，GUI操作路径过长会使过程信息淹没目标，因此应将稳定流程封装为业务能力，但适配器存在维护代价。软件边界部分源于人的认知与沟通限制；AI共享上下文能减少交接中的信息损耗，却不能替代版本管理与结果验证。上下文设计应保留会改变判断的信息，而非一味压缩或全量共享。自我改进受制于人的框架与评价漏洞，架构可能趋同于隔离、契约和一致性机制，仍需长期观察。
延伸解读
GUI 操作树：长路径下的信息淹没
文章指出，GUI Agent 通过操作树执行任务时，路径越长，进入上下文的过程信息越多，最初目标容易被执行细节包围。这并非模型必然失效，而是工程上需要追问：哪些过程信息真的需要反复交给模型理解？将稳定流程封装为业务能力，可压平操作树，但适配器有开发和维护成本，高频稳定流程值得投入，长尾偶发任务直接操作 GUI 可能更经济。
共享上下文：减少交接损耗，但不替代验证
软件边界部分源于人的认知与沟通限制，模块化减少人必须交换的信息。AI 共享上下文能让后续决策直接接触原始约束和讨论依据，减少交接中的信息损耗。但共同看到文本不等于共同拥有正确状态，两个 Agent 仍可能得出不同结论，同时修改代码仍可能冲突。共享上下文不能替代版本管理、一致性控制和结果验证。
上下文设计：保留改变判断的信息
文章区分了信息的作用：GUI 操作中的滚动、重试等执行细节通常不改变业务判断，而业务约束、历史例外和失败案例可能直接影响实现正确性。因此上下文设计不能只追求短，也不能全量共享，而应问哪些信息会改变后续判断。共享也不一定意味着复制全部材料，可以是共同可访问的资料、带版本的业务状态或按需读取的证据。
自我改进与架构趋同：保留问题，不预设结论
AlphaEvolve 找到新矩阵乘法算法，说明人提供框架不妨碍系统发现未预想方案；Darwin Gödel Machine 的评价被利用案例则提醒，指标改善可能来自评价漏洞。共享上下文下，错误成功判断也可能被继承。架构演化方面，趋同演化只是类比，不能证明软件架构必然趋同。支付幂等、共享状态协调、故障隔离等约束若仍存在，AI 可能重新发现类似机制，但需长期观察。
Q&A
为什么说让AI直接操作GUI可能绕了远路？
因为GUI操作路径过长，每一步都需要观察、判断、执行，导致截图、控件信息、失败记录等过程信息大量进入上下文，最初的目标反而被执行过程包围。将稳定流程封装为业务能力可以压平操作树，减少模型反复理解过程信息的负担。
共享上下文能完全替代版本管理和结果验证吗？
不能。共享上下文能降低信息传递成本，让后续决策直接接触原始约束和反馈，但共同看到一段文本不等于共同拥有正确状态。两个Agent读同一份材料仍可能得出不同结论，同时修改代码仍可能冲突，因此不能替代版本管理、一致性控制和结果验证。
既然要压缩上下文，为什么又要共享更多背景信息？
需要区分信息的作用。不改变后续判断的执行细节（如页面滚动次数）应压缩或交给确定性工具；而可能影响正确性的业务约束、历史例外和失败案例则值得保留和共享。上下文设计应问哪些信息会改变后续判断，而非一味求短或全量共享。
AI自我改进能突破人设定的框架吗？
人提供框架并不妨碍AI找到人未预想的方案，如AlphaEvolve找到新的矩阵乘法算法。但这不证明系统已摆脱人的目标和评价方式。Darwin Gödel Machine曾利用评价漏洞获得虚假好成绩，说明指标改善可能来自能力提升，也可能来自评价漏洞。评估自我改进需看改动了什么、验证是否独立、结果能否经受新任务检验。
AI时代的软件架构会趋同于传统架构吗？
有可能。有些边界源于人的沟通和认知限制，可能变得宽松；但另一些边界对应更难绕开的约束，如支付结果不能因重试重复生效、共享状态修改需要协调、局部故障不能随意扩大。如果这些问题仍存在，AI即使不照传统架构图设计，也可能重新发现类似的隔离、契约和一致性机制。但这只是待验证的假设。
共享上下文如何减少软件开发中的信息交接损失？
传统交接中，交接者需提前判断下一环节需要哪些细节，判断可能遗漏背景。共享上下文让后续决策直接接触相关的原始约束、讨论依据和执行反馈，不必只依赖上一环节选出的摘要。一个在需求讨论时看似无关的细节，可能在修改代码时解释古怪逻辑，从而省掉回查或避免错误修改。
