一、如何看待智能的边界
讨论 AI 时，我们很容易把目光集中在模型上：它知道多少，推理有多强，能不能规划，会不会自我改进。围绕模型搭建的记忆、工具、权限和执行机制，则常常被放在外围，仿佛模型已经包含了完整的智能，其余只是让它用起来更方便的附件。
但如果用同样的方式看人，这个划分就显得奇怪了。一个工程师能够解决问题，依赖的不只有大脑，还有感知世界的身体、操作设备的双手、可以查阅的资料、能够使用的仪器，以及身后组织提供的资源和协作。把这些逐一拿走，他能够完成的事情也会随之改变。我们看到的能力，原本就是整套系统共同产生的结果。
因此，当我们关心智能如何在现实中发挥作用时，更合适的分析单位是智能系统：承担计算与判断的部分、感知与行动接口，以及它能够支配的资源和工具。完整能力的边界，需要沿着实际发生的感知、行动和反馈去寻找，而这个边界没有固定的颗粒度。
从细胞到器官，再到具有中枢神经系统的完整个体，复杂性的增加伴随着组织方式的变化。细胞之间如何协调，器官之间如何配合，个体如何形成完整行动，分别需要在相应层级上理解。我们可以借用复杂系统的“相变”来描述这种跨越：跨过某些组织层级后，系统出现了新的功能与约束，也需要用新的规则、协同逻辑和组织单元来解释。
继续向外看，人又可以组成团队和组织，公司只是其中一种组织形式。组织的能力依赖成员，也依赖分工、制度、信息流和资源配置。即使成员不变，改变协作方式，也可能让组织能够完成此前做不到的事情。一个层级上的完整系统，到了另一个层级，就成为更大系统的组成部分；下层的能力为上层提供条件，却不足以单独解释上层如何运作。因此，分析边界应随我们要解释的功能而定。
二、生态位如何塑造智能系统
Agent 也一样。一个持续工作的 Agent，会逐渐拥有自己的状态、工具、操作权限和反馈机制。它能够看到哪些信息，如何保存尚未完成的工作，什么时候调用工具，执行失败后怎样恢复，什么情况下需要向人求助，这些通常由 Harness 承载。它们直接决定了模型能够怎样参与现实，也参与构成了整个系统的能力。
Harness 不是可选的插件，但它的工程边界并不自动等同于智能系统的功能边界。拆分与替换这些组成部分，需要以功能为依据。今天我们还不能预先认定，哪些部分可以抽走或共用，以及怎样替换后仍能保持完整能力。软件接口上的可拆卸，不自动等于系统功能上的可替代；这需要结合系统所处的生态位来验证。
设想一个帮助研究者探索新问题的 Agent。今天它读到一篇论文，提出了一个猜想；几天后，另一组实验结果推翻了其中的前提。它需要记得猜想从何而来、依赖哪些证据，并据此调整下一步研究。如果它只保存了最终结论，把推导过程和被排除的解释都压缩掉，后续探索就可能失去重要依据。
再看一个负责工厂生产调度的 Agent：一批原定今天到货的元件延期了，明天要开工的订单因此缺料。它需要查清库存里有没有可用的替代料，替代是否经过技术确认，其他订单能否先生产，以及调整后会不会影响交期。提出方案之后，它还需要在授权范围内更新计划，把变更传递给相关人员，并确认现场是否按新计划执行。这里仅有一份合理的分析远远不够，系统必须接得上库存、工艺、订单和车间的实际状态。
前者需要保存可追溯的假设与证据，后者需要连接实时业务状态，并让行动受到权限和规则约束。这些差异会进入记忆、工具和执行机制的设计，因而也影响 Harness 中哪些部分能够共用，哪些需要分别构建。
生态位所描述的，正是一个系统在环境中承担什么功能，依赖什么资源，与哪些对象发生关系，又受到什么约束。行业或岗位名称只能粗略地提示这些条件。同一家企业里可能存在多种生态位，分属不同行业的系统，也可能有相似的功能结构。
因此，智能的基本分析单位，是嵌入生态位的完整系统。
三、智能与环境共同演化
系统能力的改善与环境的改造是耦合的。还是看那批延期的元件：如果替代料的使用条件只存在于工程师的经验和聊天记录里，Agent 就得翻资料、辨认适用范围，再找人确认。如果工厂已经把“什么型号、什么工况允许用什么替代料”维护成明确规则，这一步就可以由查询和规则校验完成。环境变得清楚之后，同一个问题需要的推理量也随之减少。
反过来，实际执行的反馈又会推动系统和环境一起变化。某种替代料虽然参数合格，现场却发现它会增加装配时间；这条反馈既会改变下一次排产的判断，也可能促使工厂补充替代规则。能够学到什么、下一次怎样决策，与环境支持记录什么、反馈什么密切相关。
在这样的系统里，也没有必要让每一步都调用最强、最耗算力的模型。库存够不够，用数据库查询和数量计算就能回答；替代料是否符合已知条件，可以交给规则引擎；订单怎么安排，可以由排程算法求解。识别供应商邮件中的交期变更，可能用一个小模型就够了；碰到没有记录过的替代方案，再让更强的模型协助整理资料，由工程师判断。它们共同完成一次缺料处置，所需要的计算与判断机制却各不相同。
这也是生态位带来的分化：承担计算与判断的部分，可以由规则引擎、专用算法、不同规模和架构的模型，或人来实现。选择什么，要看它在具体环境中需要完成什么功能。不是所有器官都需要大脑皮层级的计算能力。
如果用乐高来比喻，开源模型提供了可以分化和复用的核心，而“开源模型＋生态位定义”才构成一个可工作的乐高单元。以生产调度为例，除了模型，还要明确它负责哪些订单、能够读取哪些状态、可以调整什么计划，以及如何接收执行反馈。当这些定义落实为 Harness 和环境接口，它才成为能够嵌入工厂协作的功能单元。换成规则引擎或专用算法，道理也一样：可组合的块需要有明确的功能和协作边界。
这些生态位又通过实际工作连接在一起。生产调度依赖采购提供到货信息，采购依赖技术部门确认替代方案，调整后的计划则需要车间执行并反馈结果。一个系统的行动，会改变另一个系统面对的条件。
例如，采购 Agent 更新了预计到货日期，调度 Agent 就需要重新判断计划，交付 Agent 则据此评估客户承诺。它们需要共同引用同一张订单、同一批物料及其最新状态，并明确谁有权修改计划。这样的协同，已经涉及共享环境与组织分工的设计。
因此，我更相信的未来，是各类 Agent、数字环境中的系统和人共同组成的协作网络。它们保有适合自身功能的内部结构，通过共享的业务对象、状态和接口协调行动；当网络连接到传感器、设备和执行机构时，它的作用范围还可以继续延伸到物理环境。整体能力就在这些部分的配合中形成，并随着系统与环境的相互改变而演化。
四、研究 RSI 之前，先问什么值得解决
由此再看递归自我改进（RSI），需要先回到第一性原理：这个系统为什么存在，它究竟应该解决什么问题？
如果一个 Agent 每周花费大量时间，从几个系统中复制数据、核对差异、制作报表，我们很容易把改进目标设成操作更快、出错更少。但继续追问：这份报表支持什么决策，为什么需要人工搬运数据，这些差异又是怎样产生的？最后可能发现，真正需要解决的是几个系统的业务口径不一致；统一定义并打通数据之后，整段搬运和核对流程都可以消失。此时，继续优化报表 Agent，就是在优化一个本来可以不再存在的环节。
自我改进首先需要判断什么问题值得解决、优先解决什么，以及现有做法是否还有存在的必要。生态位为这种判断提供了依据。系统承担什么功能，什么缺口妨碍了这个功能，以及在既定目标和资源约束下，消除哪个缺口最有价值，都需要在它与环境的关系中确认。没有生态位，它就没有“值得解决的问题”，也就缺少选择改进方向的依据。