就此AI
当一个人开始同时管理多个 Agent，软件工程中的一些基础问题就会换一种形态重新出现。每个 Agent 都可能在不同工作区里处理任务、读写文件、调用工具；它们最终仍要汇入同一个产品，并经过集成和发布。此时，版本控制要回答的不只是“怎样保存历史”，还要回答“哪些任务可以同时推进、它们会碰到哪些资源、冲突如何被发现和处理”。
这一讲围绕 DeepSeek Harness 展开：先从多 Agent 与真实产品的复杂性出发，再比较预先规定产品形态的架构与可扩展的插件内核。一个精简的 Harness 可以提供会话、事件总线和少量协作接口，把大量界面与应用能力交给插件。这样的设计降低了扩展成本，也把新的协调问题留给了生态本身。
一、多 Agent 把版本控制变成协作调度
单人写程序时，开发者通常是一个串行执行者：读代码、改代码、检查结果，再进入下一项工作。Agent 进入开发过程后，一个人可以同时安排多个 Agent，也可以让 Agent 再拆分任务。人的角色因此更像负责分工与验收的技术负责人，系统则要同时处理多个正在变化的工作区。
不同任务涉及的资源范围并不相同。一个任务可能只读代码，另一个需要修改某个模块，还有一个要重构系统边界。任务对同一仓库的访问可以理解为不同类型的锁：只读任务可以并行；会改变代码的任务需要写入范围；会影响接口或结构的重构则可能需要更大的独占范围。彼此无关的小修复即使都需要写入，也未必需要串行执行。
这种划分把数据库和操作系统中的并发概念带回了软件开发：可以先锁定再操作，也可以允许并行后检测冲突；可以按任务范围授权，也可以根据变更类型采用不同策略。Git 仍然负责保存提交历史和最终交付，但多 Agent 系统还需要管理工作区、任务边界、文件冲突和集成顺序。版本控制于是从保存历史扩展到协调并行工作。
二、能运行的 Agent 原型不等于可靠产品
一个很小的 Agent 循环已经可以完成有实际结果的任务：模型选择工具，运行时执行工具，把结果送回模型，再继续下一轮。它证明了基本机制可行，却不会自动解决长任务中的可靠性问题。网络可能中断，API 响应可能超时，进程也可能在任务中途结束。若没有持久化、恢复和重试机制，任务就可能只能从头再来。
重试并非简单地“失败后再请求一次”。不同网络环境有不同的延迟和故障模式，固定超时可能过短，也可能让任务卡住。连续失败时，指数退避可以避免过于频繁地重试；但系统还需要决定什么错误可以重试、最多等待多久，以及运行状态如何向用户展示。
客户端与服务端还可能对一次操作留下不同认知。客户端发出请求后若断网，服务端也许已经完成了操作，但客户端没有收到结果。此时，本地状态不是成功，也不能断定失败，而是未知。健壮的产品必须保留这种不确定性，并通过查询或恢复协议重新对齐状态，不能把“没有收到回应”直接当作“没有发生”。
产品级 Agent 还需要跨项目任务视图、会话历史、项目工具与 Skills、运行权限和隔离环境等能力。把一个“看起来像现有产品”的详细需求一次性交给 Agent，容易得到表面完整却缺少长期验证的实现。MVP 的作用是让假设遇到真实使用：网络是否稳定、用户怎样切换任务、权限在哪里确认，都可能在实际运行后改变。
三、需求变化会检验架构的边界
架构把系统分成模块，并规定模块之间怎样协作。清楚的边界能降低并行开发的依赖：模块可以由不同 Agent 分头实现，集成时再按约定连接。但每项约定都会限制自由度。当新需求恰好落在既有边界之外，代码就可能出现抽象泄漏，原先独立的模块开始互相依赖。
反过来，完全自由的消息传递也不是没有代价。所有模块都能随意发送消息，表面上减少了预先设计的限制，实际却很难判断消息的含义、顺序、所有者和失败处理。系统缺少稳定边界时，每项开发都必须理解更多全局行为，改动也更难预测。
因此架构不是在“严格”与“灵活”之间找出一个永远正确的答案，而是在不同成本之间做选择。模块化让局部开发更容易，却会使未来跨边界的需求变贵；事件溯源让状态变化有历史依据，却增加了从历史恢复当前状态的成本；自由度增加可以容纳更多应用，却也要求更明确的协议和协调方式。架构质量要结合它支持的变化、暴露的限制以及维护成本来判断。
四、薄内核让扩展能力留在生态中
DeepSeek Harness 展示了一种以会话和事件总线为中心的设计。内核提供 Agent 会话、事件注册、历史投影，以及向会话提交、追加或注入输入的接口。插件可以监听 Agent 生命周期事件，参与上下文构造，或把持久化事件投影成自己的视图。插件自己的大部分状态留在本地，只有需要协作的信息才通过约定好的事件和接口交换。
这样的内核可以承载不同形态的界面。原生 Web UI 可以使用插槽装配页面；终端界面可以监听同一会话的事件，把内容投影到命令行；开发者也可以通过插件添加终端、侧栏、额外会话或实时状态面板。应用不必把每一种使用方式都预先做进主程序，插件可以围绕共同的会话与事件协议构造能力。
Creator Mode 把这种扩展推进到运行时：开发者可以在 Agent 工作时安装或调整插件，甚至创建新的界面和工作流。这让 Harness 更像一个供生态继续构造的内核，而不是功能已经全部封装好的单一产品。它把“增加功能”从修改主程序转为遵循协议添加扩展，也让原型和社区实验更容易出现。
但插件架构无法自动协调插件之间的语义。两个插件都能修改上下文时，先检查还是先改写会影响结果；多个压缩插件叠加时，信息可能被过度删减；一个插件要求停止、另一个要求继续时，事件系统必须有明确的冲突处理规则。类型匹配只说明消息形状符合协议，不代表插件的行为在含义上兼容。
插件降低的是扩展时的偶然复杂性，并没有消除软件本身的本质复杂性。权限、事件顺序、共享状态、冲突处理和责任归属仍需要设计。Creator Mode 的能力越大，运行时权限和隔离边界就越重要；插件生态越自由，对协议治理和失败诊断的要求也越高。
五、把现有应用接入 Agent 工作流
事件总线还能把 Harness 与已有的超级应用连接起来。以编辑器、表格或绘图工具为例，接入层可以提供一组很薄的桥接操作：锁定用户选中的对象，把对象交给模型处理，再将结果提交回原应用。应用仍负责自己的编辑体验，Agent 负责生成或修改内容，桥接层则管理对象的交接与锁定。
这种方式可以让 AI 能力进入已有工作流，而不必先重做整个应用的编辑器。模型完成修改后，用户仍可以继续移动、删除或编辑生成的对象。应用也可以把动态界面作为插件插入会话，并通过事件把交互状态传回模型。它拓展了可组合空间，同时要求应用和 Agent 对对象身份、修改范围与提交时机形成稳定约定。
更大的设想是把个人数据、工具和多个应用放在同一个 Agent 生态中协作：某个应用提出任务，Agent 调用合适的插件获取信息或执行操作，再把结果送回原来的工作界面。要实现这种协作，不能只依靠模型理解上下文，还要有明确的授权、数据边界和可追踪的操作过程。生态能否成立，取决于这些接口能否安全、清楚地组合。
六、架构提供机会，也留下协调工作
一个小内核可以不替所有用户预先决定产品形态。稳定的会话和事件协议为插件留下空间，开发者可以快速试验界面、工具桥接和工作流，再让有价值的方案在生态中成长。与一次性把庞大需求全部实现相比，这种方式更容易让新需求先以局部扩展的形式出现。
代价是系统不再由单一团队完全控制。插件可能彼此冲突，语义约定可能不足，权限也可能跨越应用边界。基础架构应明确哪些能力属于内核、哪些状态由插件拥有、插件怎样组合，以及出现冲突时谁负责处理。内核越薄，生态治理的责任越不能含糊。
Agent Native 开发带来的变化，不只是让代码生成得更快，而是让更多角色、工具和应用同时参与软件生产。工程工作的重心因此扩展到任务分解、状态协调、权限控制、架构演化与生态协议。好的 Harness 不需要预先包含所有功能，但要提供足够清晰的边界，让新的能力能被接入、理解、验证和维护。