Matrix Land SI 是如何运作的

上一篇从 Excel 写到 SSOT，最后留下的问题是：如果软件可以随着业务需要生成，一个公司应该把什么固定下来，又把什么交给每个同事自己做？Matrix Land SI 就是从这个问题开始的。

以前，部门需要一个工具，要先把自己的工作翻译成需求，再等产品、开发、测试和上线。有些需求太小，根本排不上队。最后大家还是回到 Excel，在现成系统旁边，靠一张表、几个文件和聊天记录把事情办完。公司真正怎样运作，往往藏在这些系统之间。

AI Coding 让同事有机会直接把这些工作做成应用，Agent 则可以跨过不同应用的界面去调用业务能力。新的问题随之出现：每个人都能创作以后，谁来保证客户还是同一个客户，数据没有各抄一份，应用没有悄悄多拿权限，做出来的东西下周还找得到、用得了？

我们把这些事分开处理。与具体业务贴得很近的部分，交给业务同事创作；身份、权限、资料、运行资源和发布记录，由平台提供共同的基础。Matrix Land SI 要承接的，就是两者之间那些原本需要反复协调的工作。

这张图里，我更关心中间的 AI Capability Commons。上面的业务团队有各自的客户、流程和专业判断，下面有工程与运行支持。中间这一层，把模型、知识、应用创作和云资源交到业务同事手上。它服务所有部门，也允许每个部门做出不一样的东西。

在平台的具体分工里，LEGO 管应用、资源与发布，Knowledge 保存资料和版本，Mate 承接对话与任务，Workspace MCP 提供工具入口，Auth 提供可信身份与授权依据。把这些能力连起来，是为了让同事把精力花在自己的业务上。至于业务对象怎样定义、哪些动作能够开放，仍然需要各个业务单元逐步整理。

看一个公司的系统，很容易先看到软件品牌：用了哪套 ERP、哪套 CRM，文档放在哪里，报表在哪个页面。我更愿意先问，公司的事实究竟存在哪里，谁说了算。

一笔交易是什么时候发生的，客户当时授权了什么，哪个版本的规则适用于它，后来为什么做了调整。这些东西是公司做过生意、作过决定以后才留下来的。买一套更好的软件，或者接一个更强的模型，都不能替公司补出这段历史。

所以，在这套平台的取舍里，我把数据视为公司唯一需要持续积累、自己掌握的数字资产。这里的数据包括业务记录，也包括合同、研究资料、规则版本和处理结果。模型可以更换，界面可以重做，程序可以重新生成；过去发生的事情，以及当时作判断的依据，丢了就很难补回来。

数据换了容器，事情还是那件事情

这些数据大致住在三类地方。第一类是 ERP、CRM 等已有系统，结构比较明确，自由度也低。第二类是部门自己做的应用，我更喜欢叫 Local App：为某个职能、某群同事的具体工作而生。第三类是文档、表格、邮件、录音和其他多媒体，表达自由，但需要花更多力气才能确认里面的事实。

从第一类到第三类，大体是从高结构、低自由度，走向低结构、高自由度。一个公司过去十年的数字化，往往就是把某些事情从第三类搬到第一类。现在多了第二类，同事可以先把自己的小范围工作整理起来，不必每件事都等一个全公司的系统项目。

三类来源都可以通过工具接口供 Agent 使用。但接口接通，只解决了“读得到、调得动”。两份文件互相矛盾，两个系统都叫同一个客户“有效”，却各有各的定义，模型再强，也不能替业务负责人决定哪一份才算数。

SSOT：权威、唯一，而且口径清楚

上一篇谈的 SSOT，在公司里需要落实到具体对象。比如一位客户，究竟用哪个标识确认身份，基本资料由谁维护，其他应用引用哪个来源。一个应用为了显示方便保存了副本，不意味着它又多了一份可以自行修改的客户主档。

“唯一”要带着范围说。客户的法定名称、服务关系、最近一次接触时间，可能分别由不同业务负责。财务确认的收入和销售计算的业绩，也可以不同。需要唯一的是，在一个明确的问题、对象和时间范围内，大家知道应当去哪里取数，并能解释这个数怎么算出来。

例如“本月新增客户”这个数，如果没有说清开户、审核通过还是首次成交，没有说清按哪个时区截月，几个部门报出来不一样很正常。把它们都塞进同一张数据库表，不会自动消除分歧。应该先把问题写清楚，再确定各自的事实来源和计算口径。

Ontology：把业务对象和能做的事一起说明白

SSOT 让我们知道事实从哪里来。Ontology 进一步告诉使用者，这些事实在业务里意味着什么。它要描述客户、账户、产品、订单这些对象，描述谁拥有哪些账户、订单属于哪位客户，也描述一个对象在什么条件下可以执行什么动作。

拿“客户”来说，仅仅有一张 customer 表还不够。我们需要知道这里指自然人、法人还是服务关系；一人多个账户怎样关联；关闭账户是否等于终止客户关系；谁可以更新联系方式，谁可以改变服务状态。业务同事平时依靠经验知道的这些区别，需要被明确下来。

这样，销售看的是自己要跟进的客户，运营看的是材料和处理进度，其他同事按职责看到相应信息。各自的页面可以不同，临时生成的视图也可以不同，但它们引用的对象身份和事实来源能够对上。某个视图发现错误，应当向负责该事实的地方提出修正，而不是在自己这边另改一份。

Ontology 因而需要业务负责人持续参与。系统可以帮忙找同名、识别冲突、补充关系；“什么才算完成”“哪种状态可以进入下一步”，仍然来自组织自己的约定。给旧字段换一套术语，解决不了这个问题。

从软件操作到 Agent 操作，什么没有变

传统程序按写好的逻辑计算；LLM 可以处理模糊描述、作推断，也可以写代码执行精确计算。从业务结果看，它们常常在做相同的两件事：把一个对象从某个状态推进到下一个状态，或者产生一项新的记录。

变的是操作这些事实的方法。过去，人打开应用，沿着页面和流程一步步完成；现在，Agent 可以查资料、调用接口、运行程序，再把结果组合起来。无论哪一种方法，推断都需要和已经确认的事实区分，更新都要回到负责它的业务接口。模型说“应该已经完成”，不能替代系统里的实际完成记录。

如果应用的界面以后越来越容易生成，留在公司手里的这层数据就更重要。今天的 App、明天的 Agent，都在使用它。我们要逐步整理的，是这些对象的定义、来源、关系和操作规则，让新工具能接着已有的业务积累工作。

前一节把数据单独拿出来，是因为接下来要变的，是使用这些数据完成工作的计算方式。过去，业务人员操作界面，程序执行事先写好的逻辑。现在，越来越多判断和执行可以交给模型。我们需要重新考虑：哪些步骤必须预先确定，哪些方法可以让 AI 在工作过程中选择。

这里有两种自由度。一种是计算自由度：每一步怎样理解输入、作判断、形成结果。另一种是路径自由度：先做什么，后做什么，遇到新情况以后，是否可以换一种办法。沿着直接交付业务结果这条线看，这两种自由度是在逐步打开的。

第一阶段：UI 驱动，计算与路径都预先定义

传统软件里，人打开页面，填写字段，点击按钮，程序按精确定义的规则处理。计算公式、条件分支和后续动作，大多在开发时已经写好。页面可以支持很多操作，流程也可以有很多分支，但程序能走的路，要先有人定义出来。

例如材料检查，系统可以按清单判断文件有没有上传，也可以校验日期格式、必填字段。遇到一份名称不规范、内容却可能符合要求的文件，它往往需要人处理，或者等开发者增加一种规则。程序不会因为理解了这次业务的目的，就自行决定换一个来源继续核实。

这时，计算和路径的自由度都比较小。系统之外，人一直在做补充判断：打开附件看一眼，去别的系统查一下，再回来继续。很多工作实际上是由人穿过几个软件完成的。

第二阶段：Workflow 固定路径，AI 在节点内计算

接下来，我们开始把模型放进流程节点。收到文件后，先让 AI 识别内容，再做分类，然后进入检查、审批、归档。原来很难写成精确规则的判断，终于可以交给模型处理。

但整个任务仍然由 Workflow 框住。模型可以在一个节点里理解复杂材料、选择措辞、作出分类；这个节点之后去哪里，通常仍由预先设定的连线和分支决定。计算自由度打开了一部分，路径自由度还掌握在流程作者手里。

比如 AI 发现材料里两处信息互相矛盾，如果流程只给了“通过”和“退回”两个出口，它就只能按已有出口处理。它不能自然地把整件事改成“先去另一个权威来源核对，再回来判断”，除非作者提前把这条路也画进去。

因此，这种模式的自由主要留在节点里。即使节点内部能够作复杂推理，整体策略仍然受既定路径限制。要改变完成任务的方法，往往需要人回来修改 Workflow。对于顺序必须固定、每一步都有明确要求的工作，这种约束有价值；只是它不会自动给 AI 留出重新组织整项工作的空间。

第三阶段：Harness 约束边界，AI 选择方法和路径

再往前一步，我们交给 AI 的是一项有验收条件的任务，同时说明它可以用什么资料、调用哪些工具，哪些动作必须确认，遇到什么情况需要停下来。具体先查哪里、怎样核对、是否重试或换一种方法，可以由 AI 根据执行结果决定。

仍然拿材料检查来说，目标是提交一份有依据的检查结果。AI 可以先读文件，发现冲突后查询获授权的业务记录，再判断是否需要补充材料。只要没有越过数据、操作和责任边界，它不必每次沿着同一条路线完成任务。

这时需要 Harness。它把目标、可用工具、运行状态、权限、检查和人工接管安排在一起，让 AI 的判断与执行有一个实际运行的框架。我们不再要求把每一条可能的路径事先穷举出来，但必须能够约束它的行为，并检查它最后交付了什么。

这里打开的是方法和路径的选择。精确计算仍然交给合适的程序，必须固定的业务步骤仍然保留。一个 Harness 里可以调用已有 Workflow；AI 也可以判断，当前任务适合直接执行一段已经验证过的流程。不同方法可以放在同一个任务里使用。

自由度打开以后，什么必须纳入体系

以前，一部分限制写在页面和路径里：按钮不能点，流程不能跳，某个分支不会出现。现在允许 AI 自己选择方法，这些限制就需要明确落实在数据和动作上。不能因为它换了一条路，就读到原本无权访问的资料，或者完成原本需要审批的修改。

所以，数据读写要严格按权限执行。可读哪些对象、可改哪些字段、以谁的身份调用，都由实际服务检查。目标即使合理，也不能自动带来额外授权。给 AI 一项“把事情办好”的任务，不等于把所有资源都交给它。

方法也要能够循证。它读了什么资料，为什么采用这组数据，做了哪些计算，调用了什么工具，返回结果是否支持结论，都应当有可以核对的依据。这些依据来自资料、计算和执行记录；仅有一段听起来完整的解释，不足以证明工作已经完成。

还要把验收和例外处理放进同一个框架。完成条件是什么，怎样检查结果，不符合时能否重试，什么时候必须交给人，都需要有安排。AI 承担结果交付，是要它把任务推进到可验收的结果；业务单元仍然负责设定标准、授予权限和接管超出范围的事情。

光谱的另一端：始终有人掌握方向的辅助驾驶

上面这条演化线，是从直接交付业务结果的角度展开的。一直以来，还有一条平行路径：从 Chatbot 到可以执行任务的 Agent，人始终在旁边主导工作。Agent 能做的事越来越多，但它依然作为辅助驾驶存在。

这条路径特别适合开放、探索性、启发式的协作。学习一个新领域时，人会边问边发现自己哪里没懂；研究一个问题时，新证据可能推翻原先的假设；做一次性的 Coding Demo 时，往往要先看到一个能运行的东西，才知道自己真正想做什么。

这些任务开始时，目标和验收条件未必足够清楚。人的参与会不断改变任务本身。Agent 可以找资料、提出反例、跑实验、改代码，人则持续判断哪些方向值得走。过程中的理解和启发，本身就是成果的一部分。

所以，辅助驾驶有它天然的优势。研究员需要看见证据怎样形成结论，学习者需要自己建立理解，应用作者需要在试用中形成判断。即使 Agent 可以独立执行很长一段工作，也不必因此把方向选择和最后判断全部交出去。

平台支持两端，也支持它们在任务中相遇

我们看到的趋势是，LLM 计算既能承担越来越复杂的日常任务，也能参与启发式的探索。平台需要支持这两端：一端按约定交付业务结果，另一端与人一起学习、研究和创作。中间还有大量可以具体安排的分工。

一次探索可能产生一项清楚的子任务。研究员想明白了要核对什么，就可以把数据核验交给 AI 独立完成；结果回来以后，再一起讨论新的解释。反过来，一项日常任务遇到从未见过的情况，也可以转入人机共同判断，等处理方法确定后，再决定是否纳入后续运行。

不同部门、不同的任务能力要求、不同合规约束，以及使用人员的经验构成，会让同一种技术落在光谱上的不同位置。有的场景适合直接交付，有的需要保留几个决定点，有的则更适合全程伴随。具体位置，要用具体任务的要求、实际表现和可接受的授权范围来确定。

AI 计算优先，是做这类设计时，先认真考虑哪些理解、判断和执行可以交给 AI，再把人的决定点、严格的数据权限和可核对的结果安排进去。也可以把这种取向叫作 AI Maxxing：充分使用 AI 的计算能力，同时让它进入公司的业务和责任体系。

作为 Monica 和 Manus 的早期用户，我很多次跟身边的人解释，我理解的 Manus 竞争力是什么：看得见极琐碎的细节，然后还能持续解决。一个个看，可能都不是什么大功能，放在一起，就成了别人很难补齐的东西。

以前 red 不管几点，遇到 VPN 环境和 S3 存储导致图片识别困难这种边缘问题，也会半夜拉群解决。我记得这件事，是因为它很难出现在一份漂亮的产品规划里。对遇到问题的人来说，图片就是读不出来，工作就是卡在这里。能不能继续用，取决于有没有人愿意把它解决。

大厂未必缺工程师，也未必不知道该怎么修。但一个细节要经过分类、优先级、排期，很容易被认为不够典型、不够大。流程看上去很理性，长期下来，却可能让人看不见真实使用中的问题。Hands Dirty On 的第一道门槛，是能不能、愿不愿意看见。

一线同事创作应用，道理也在这里。每天做这项工作的人，知道哪个字段容易填错，哪一步总要去群里补问，哪种情况不能按默认流程处理。很多需求没有大到值得立一个项目，却足够让他每天多花半小时。

Manus 2.0 给我的启发

读 Manus 2.0 关于游戏开发的介绍，我最有感触的是它怎样让人持续参与。游戏能运行以后，人还要调手感、换素材、找朋友一起玩。模型把代码写出来，只完成了其中一部分。

参数面板让人一边玩，一边调速度、重力和难度；素材管理让人替换角色、画面和声音；托管多人服务，让作品能够真的交到朋友手里。这几件事分别解决的，是“我能不能改”“我能不能做成自己的样子”和“别人能不能真的用”。

企业应用同样需要这几种能力。业务同事做出第一个版本以后，应该能根据实际使用修改字段、调整排序、换一套展示方式；可以管理应用用到的模板和文件；能够把它交给有权限的同事使用，并在下一次修改出问题时，知道怎样恢复服务。

比如运营同事做一个材料跟进工具，第一次试用后发现，按提交日期排序没有用，真正影响处理的是缺哪一种材料。接着又发现，同一位客户的几次补交应该放在一起。只有让他参与每一轮修改，工具才会逐渐贴近工作。让他把每个细节重新解释给一个不在现场的人，来回几轮，很可能又回到了最初的排期问题。

为什么 AI Coding 是重要的入口

企业里大量工作已经由软件承载，金融业务尤其如此：资料收集、客户服务、运营处理、研究记录，都有可以数字化的部分。要改变这些工作，AI 可以直接参与修改承载它们的程序。

我看重 AI Coding 的一个原因，是代码有比较明确的反馈。程序能不能运行，字段有没有保存，某个计算和已知样例是否一致，权限外的用户能不能访问，都能检查。业务同事还可以拿真实工作中的例子试用，指出结果哪里不对。

这种可检查性，使 AI Coding 成为 AI 进入企业工作的一个实际入口。可靠的应用仍然需要验证、维护和责任人，但我们已经可以把很多原先只能口头描述的想法，较快做成一个能试、能改的版本。业务判断由人带进来，程序负责把它落实为可重复使用的工具。

Local App：就为这一群人、这一件事

我更喜欢 Local App 这个词。这里的 local，指它属于一个具体的职能、部门或工作现场。它可以运行在云上，也可以只服务十几个同事。有没有资格存在，要看它是否解决了这群人的问题。

过去做软件的成本高，我们很容易要求一个新应用同时满足很多部门。需求越合并，具体细节越需要让步。现在，创作成本下降，一个只解决材料补交、会议准备或某类资料检查的小应用，也有机会被认真做出来。

部门应用多起来以后，最需要避免的是各做一份客户表、各记一份员工名单。界面和工作方法可以贴近部门，权威事实仍然引用负责它的来源。一个小应用用完以后可以停止维护，它处理过的正式记录和文件，则应当能够保留下来、被后续工具接着使用。

从 Idea 到产品，需要一个有人维护的 System

Vibe Anything 要进入日常生产，很多时候卡在模型之外。代码版本放在哪里，应用怎么部署，文件怎样保存，数据库怎样跟着新版本变化，出了问题怎样找到负责人。这些事情高度结构化，也十分琐碎。每位业务同事都从头学一遍，创作门槛就又回来了。

所以 Idea 到产品，仍然需要一个隐藏在创作过程后面的 System。版本、部署、素材、数据结构和访问规则，都要有人管。技术细节可以收起来，但它们需要真正运行，不能靠一段“发布成功”的对话代替。

这也是我觉得云有机会成为 AI 时代超级 App 的原因。计算、存储、数据库、网络，本来就在云上；模型和 Agent 又需要这些能力。Cloudflare 这样的产品给工程师提供了很多组合空间，但只看左侧菜单，就足以劝退许多业务同事。一个更容易使用的云入口，仍然有大量工作要做。

Matrix Land SI 的 LEGO 承担其中一部分：把应用身份、代码、资源和发布版本关联起来，让创作过程有地方落脚。Auth 接住身份与权限，Knowledge 接住共同资料，业务接口继续负责自己的记录和规则。业务同事不需要独自搭建整套基础设施，但要有人持续照看他做出来的应用。

从大模型套壳到云套壳，这两件事已经够脏、够难。把成熟能力整理成普通人用得起来的服务，里面的细节需要一件件做。所谓分发，在这里很具体：一个原来不会部署应用的同事，终于能把工具交给自己的团队用；发现不对，第二天还改得动。

一个员工过去需要打开几个应用，分别完成几步操作。Agent 可以把这些步骤接起来，效率会提高，但原先藏在应用界面里的权限问题也会暴露出来。它用谁的身份查询？能看哪些客户？读到一份文件之后，是否就能修改？替另一个 Mate 调用工具时，权限会不会越传越大？

这些问题要在工具开始执行之前有答案。等应用已经做完、同事已经用起来，再补一套身份和授权，很容易变成到处加例外。

统一的是调用方式和身份依据

MCP 给 Agent 提供一致的工具描述和调用方式。查知识库、读业务记录、维护应用，不必在每个工作台里分别教一遍。Workspace MCP 把这些入口整理起来，让获授权的 Agent 能发现工具、理解参数并发起调用。

但 MCP 本身不会替业务决定谁有权看谁的客户。Matrix Land SI 的统一入口要和 Auth、Knowledge、应用自己的权限检查配合。员工身份从可信的登录和授权过程取得，资源服务继续判断这次具体操作是否允许。

比如一位销售同事在工作台里说“帮我整理客户资料”。Agent 首先要代表这位同事调用，再按他的权限取得资料。不能因为工具背后有一个权限更高的创建者，就把创建者能看的内容都交给他。能调用一个 Mate，也不意味着继承了 Mate 所有者的全部权限。

能进入应用、能管理应用、能改业务记录，是不同的事

一个同事可能可以打开应用，却不能发布新版本；也可能负责开发应用，却没有理由读取所有客户记录。知识库的阅读、编辑和成员管理，同样是不同权限。把这些事情区分清楚，业务团队才能放心地让更多人参与创作。

协作光谱上的不同方式都应遵守这些区别。辅助工作台里的 Agent 代表当前员工完成任务，不能超出他的授权。直接承担结果交付的 Agent，则需要明确运行身份、可用资源和操作范围，不能因为可以自主选择路径，就拿一份无边界的管理权限。

在 Matrix Land SI 当前的 Mate 运行中，知识库和 App 调用仍然会检查实际员工的授权，Mate 的发布配置还能继续缩小工具范围。一份 Handbook 可以写工作方法，却不能通过文字给自己增加数据库权限。业务单元今后怎样安排更多自动任务，也必须把运行身份和授权关系交代清楚。

把规则放在执行处，让工具可以自由组合

如果每个新应用都要单独造登录、配密钥、猜部门名单，业务创作很快会被这些工作拖住。统一的身份依据、资源授权和 MCP 接口，把反复出现的部分做好，应用作者就能继续处理自己的业务细节。

同时，具体动作必须由负责它的服务守住。查询客户的接口检查能查哪些客户，更新状态的接口检查允许从什么状态改到什么状态，知识库检查谁能改这份文件。换一个模型、换一个工作台，或者把动作放进自动任务里，这些规则都要继续成立。

做到这一步，部门才有条件放心做小应用，也有条件把其中一些重复工作交给数字员工。它们可以更换页面、调整工作方法、组合已有能力，而不必每次都重新决定公司的身份和数据归属。