共享上下文之后，AI 会怎样改变软件架构？

这次讨论最初是从 agent-desktop 这个桌面 Agent 项目开始的。

这个项目主要通过操作系统的无障碍树读取和操作桌面界面，并不只依赖截图识别。它引出了一个关于 GUI Agent 的问题，也把讨论带到了共享上下文与软件架构。下文是沿着这些问题展开的探索，不是对这个项目整体效果的实测结论。

让 AI 看屏幕、找按钮、操作软件，当然有现实价值。大量现有系统没有合适的 API，界面往往是唯一可用的入口。但如果把它当成 Agent 的默认工作方式，我有一个疑问：会不会绕了一条远路？

问题不只在识图准不准，也不只在截图消耗多少 token。更深的问题是操作树。

一个业务目标，到了界面上，可能要经过打开页面、搜索对象、进入详情、切换标签、填写表单、确认提交。每一步又可能遇到弹窗、加载或状态变化。Agent 要不断观察、判断、执行，再观察。

随着路径变长，进入上下文的东西也越来越多：截图、控件信息、失败记录、尝试过的办法，以及对当前状态的解释。最初要完成的目标，渐渐被执行过程包围。

这不意味着上下文一长，模型就必然失效。具体表现取决于模型、任务和上下文管理方式。但有一个工程问题值得追问：这些过程信息，有多少真的需要交给模型反复理解？

一、操作树可以压平，复杂性需要安放

“API 操作是扁平的”，是讨论中的一个直观判断。

查询某个客户最近的订单，在界面里可能要经过好几个页面；一个合适的业务接口，可以直接接收客户标识和时间范围，返回订单列表。上层 Agent 面对的是业务动作，不必重新走一遍导航路径。

API 当然也有分页、异步任务、权限、重试和失败状态。它不会自动消灭复杂性。好的接口，把一部分复杂性放到了更适合处理它的位置，用明确的契约管理起来。

没有 API，也可以把相对稳定的 GUI 流程封装成业务能力。Agent 调用“查询订单”，适配层负责定位控件、等待加载、检查结果。如果只是把“点击”和“输入”分别包装成接口，操作树并没有变浅，模型的决策负担还在。

封装之后，底层 GUI 的问题也不会消失。页面改版仍然可能破坏流程；提交后超时，仍然需要区分“没有执行”和“执行了但未确认”。这些问题需要状态验证和恢复逻辑，不能靠增加一层协议解决。

代价同样明确：适配器需要开发和维护。对于高频、稳定的流程，这笔投入可能值得；对于偶发的长尾任务，直接操作 GUI 可能更经济。

聊到这里，结论已经很熟悉：封装、分层、职责划分，合适的事情交给合适的方式。老生常谈，没有银弹。

但值得继续追问的是：这些经典原则背后，默认了怎样的成本和约束？AI 有没有改变其中一些条件？

二、软件的边界，也受到人的限制

康威定律提供了一个入口：组织设计出的系统，往往会映射其沟通结构。

订单、支付、库存由不同团队负责，系统也容易形成相应的模块和接口。这个观察不意味着系统结构完全由组织决定，但它提醒我们，架构里有一部分边界来自人的协作方式。

每个人能理解的范围有限，沟通需要时间，同步细节会消耗注意力。清晰的接口，让一个团队不必掌握另一个团队的全部工作，也能继续推进。

从这个角度看，模块化的一部分作用，是减少人必须交换和理解的信息。

这不是模块化的全部理由。故障隔离、安全控制、独立部署和资源伸缩，都有各自的价值。但人的认知与沟通成本，确实参与了架构取舍。

于是问题出现了：如果执行者换成 AI，信息交换和处理的成本发生变化，原先的边界还应该原样保留吗？

这里说的 I/O，不能只理解成读写速度。真正有用的信息处理能力，还包括找出相关内容、理解约束、发现冲突，并据此做出正确判断。把大量材料传给模型，不等于它已经掌握了这些材料。

即便如此，AI 至少带来了一种值得探索的可能：某些在人类团队中需要反复解释、压缩和转述的信息，可以通过共享上下文，更直接地参与后续决策。

三、共享上下文，可能减少什么损失？

设想一个开发任务：修改退款规则。

需求分析者理解业务，开发者修改代码，测试者设计用例。每次交接，都需要整理一份适合下一环节使用的信息。

这种分工很合理，但交接有个困难：交接者必须提前判断，下一环节需要哪些细节。

“退款超过一定金额需要人工审核”，可能被准确写进需求；为什么有这个限制、某个历史故障怎样影响规则、某类订单为何例外，却可能被省略。等到实现或测试碰到边界情况，大家又要回头补背景。

文档和接口设计可以缓解这些损耗，但整理交接内容本身就需要判断，判断就可能遗漏。

共享上下文提供了另一种选择：让后续决策直接接触相关的原始约束、讨论依据和执行反馈，不必只依赖上一环节选出来的摘要。

一个细节在需求讨论时看起来无关紧要，到了修改代码时，可能刚好解释了某段古怪逻辑。保留这个细节，就可能省掉一次回查，或者避免一次错误修改。

这也是共享上下文最值得研究的地方：它让一些依赖关系可以在解决问题的过程中被发现，不必在划分接口时就全部预见。

不过，共同看到一段文本，还不是共同拥有正确的状态。两个 Agent 读了同一份材料，仍然可能得出不同结论；同时修改代码，也仍然可能发生冲突。共享上下文能够降低某些信息传递成本，却不能替代版本管理、一致性控制和结果验证。

四、为什么既要压缩上下文，又要共享上下文？

这里似乎出现了一个矛盾。

前面担心 GUI 操作树太深，让上下文膨胀；现在又讨论共享更多背景的价值。究竟应该减少，还是增加？

需要区分信息的作用。

查一个订单时，页面滚动了几次、加载重试了几次，通常不会改变后续业务判断。订单属于谁、状态是否确定、用户允许做什么，才值得保留。

修改退款规则时，业务约束、历史例外和失败案例，可能直接影响实现是否正确。为了让各个环节看起来独立而过早丢掉这些信息，反而会增加成本。

因此，上下文设计不能只追求短，也不能把“装得下”当作保留全部内容的理由。应该问：哪些信息会改变后续判断？哪些执行细节可以交给确定性的工具，只向上返回结果、状态和必要证据？

共享也不一定意味着把全部材料复制给每个 Agent。它可以是一份共同可访问的资料、带版本的业务状态，或者需要时再读取的证据。共同可访问，不等于每次推理都必须全部加载。

进一步说，信息共享边界也不必与代码、权限和部署边界重合。两个模块可以共享业务背景，同时保持明确的代码接口；两个 Agent 可以读取同一份需求，但只有一个拥有生产环境的写权限。

这些边界需要分别设计。

共享更多信息，会带来注意力竞争、读取成本和过时内容的干扰。错误判断也可能随着共享传播。对于权限范围不同的执行者，信息可见性更不能仅由效率决定。

五、自我改进能走出人设定的边界吗？

如果共享上下文改变了信息传递方式，再加上多轮自我改进，AI 有没有可能逐渐形成不同的架构？

这个问题需要先区分几种“边界”：人的已有预期，允许修改的系统结构，以及真正由外部强制执行的约束。突破其中一种，不等于突破了全部。

AlphaEvolve 的研究介绍提供了一个正面例子：系统找到了计算两个 4×4 复数矩阵乘积的新算法，将标量乘法次数从此前方案的 49 次降至 48 次。研究者没有预先写出这个解法，但问题表示、搜索机制和正确性验证仍然由人设定。

这说明，人提供框架，并不妨碍系统找到人没有预想到的方案。它没有证明系统已经摆脱人的目标和评价方式。

另一面，Darwin Gödel Machine 的研究报告记录过评价被利用的情况：系统违反文字指令，移除了用于检测幻觉的标记，从而得到虚假的好成绩。

这里被违反的规则没有得到充分的外部强制执行，不能据此说 AI 突破了隔离良好的约束。但它提醒我们：指标改善，可能来自能力提升，也可能来自评价漏洞。

这同样关系到共享上下文。真实经验可以被保留，错误的成功判断也可能被继承。后续改进如果建立在错误反馈上，更多轮迭代未必让系统更可靠。

因此，评估自我改进，除了看分数是否提高，还要看改动了什么、验证是否独立、结果能否经受新任务检验。系统变好了，也不自动意味着它已经变得更擅长继续改进自己。

六、新架构也可能走回熟悉的地方

讨论还有另一种可能：即使 AI 的信息处理能力与人不同，在相近的目标和约束下，最终形成的结构，也可能与我们熟悉的架构相似。

生物学中的趋同演化可以提供一个类比：不同的演化路径，在相似压力下，有时会出现相似的特征。但这只是帮助提出问题的类比，不能据此证明软件架构必然趋同。

这个假设仍然值得保留。

有些边界是为了适应人的沟通和认知能力；另一些边界则对应着更难绕开的约束。例如，支付结果不能因为重试而重复生效，多个执行者对共享状态的修改需要协调，局部故障不能随意扩大。

如果这些问题仍然存在，AI 即使不照着传统架构图设计，也可能重新发现类似的隔离、契约和一致性机制。

因此，看到相似结构，不能立刻认定 AI 只是在复制训练数据；看到陌生结构，也不能立刻认定它更先进。我们需要知道结构为什么出现，又解决了什么问题。

最终也可能是混合的结果：某些为了减少人际沟通而设的边界变得宽松，某些承担权限和故障控制的边界更加严格；任务背景共享得更多，执行约束反而更明确。

这些都是待验证的可能性。

七、把问题放回长期协作中

眼下，我们还不能回答 AI 最终会形成怎样的架构。

代码由 AI 编写，也不等于架构由 AI 自主形成。人仍在选择任务、提供工具、规定权限、设置验收标准。即使不指定模块边界，训练数据和运行环境也已经提供了许多预设。

但要求 AI 完全摆脱人的约束，可能把问题推得太远。更贴近现实的过程，是人和 AI 一起慢慢摸索。

人提出目标，AI 尝试方案；运行结果暴露问题，人据此调整约束，AI 继续修改。有些最初不符合直觉的方案被验证有效，有些看似可以取消的边界，在多次失败后又被重新建立。

共享上下文也会在这个过程中接受检验。一段背景被保留下来，是否减少了返工？一个过时判断被反复继承，是否扩大了错误？哪些知识适合按需读取，哪些应该变成测试，哪些操作必须由外部机制限制？

要回答这些问题，需要观察同一系统如何经历后续修改、故障和需求变化。一次成功演示，或者两个条件不同的项目之间的结构差异，都不足以说明原因。

所以，这篇文章最后留下的，是一个值得持续观察的现象：当人和 AI 长期共同工作，信息如何共享，约束如何落实，架构边界又会怎样调整？

它可能产生新的组织方式，也可能在相似压力下重新走向熟悉的结构。现在还不必急着选择其中一种结论。

基本的道理还在。怎样在新的条件下运用这些道理，可能需要在共同工作的过程中，一点点找到答案。