讨论哪里能用Agent之前，先重新理解职能和组织分工

设计一个企业 Agent，首先会遇到边界问题。我们可能很快给它起名叫“采购 Agent”“销售 Agent”或“项目管理 Agent”，但这些名称还没有说明：它究竟承担什么功能，需要依赖谁的工作，产出交给谁，又能在什么范围内作出决定。

在《智能系统、生态位与 Agent 网络》中，我把这些问题放在生态位中理解。到了企业场景，明确生态位，就需要进一步理解组织内部的分工。

从交易成本的角度看，公司存在的一个重要原因，是将原本需要反复寻找交易对象、谈判和协调的活动，纳入相对稳定的组织关系。但这些活动进入公司以后，仍然需要被划分和衔接：谁提供什么，谁承接结果，谁作出判断，以及谁对结果负责。组织通过分工与协作，把不同参与者的能力组合起来。

Agent 进入企业，也会进入这套分工关系。一个“采购岗位”可能同时包含需求核实、供应商选择、订单执行和交期跟进，每一部分又与技术、生产、财务等工作相连。直接沿用岗位名称，仍然无法确定 Agent 应该承接其中哪些部分。

而现有组织对这些边界的描述，也未必足够清楚。企业通常都有部门职责和岗位说明书，但具体事情发生时，仍然可能几个部门都说与自己有关，却没有人对最终结果负责；或者每个部门都完成了自己的工作，中间仍有一个环节无人承接。

要把这些关系讲清楚，需要明确业务需要完成什么功能、涉及哪些对象，再确定由谁在什么范围内承担。职能，正是连接业务需要与执行主体的中间层。

一、职能已经存在，只是散落在文本里

部门职责、岗位说明书和招聘 JD 中，已经包含大量职能描述：维护客户关系、管理销售合同、确认技术方案、保障物料供应、核算成本。

这些描述可以进一步拆成一个基本结构：

对什么业务对象，承担什么责任。

例如，“负责销售合同管理”，能看出负责对象是“销售合同”，但仍然比较宽泛。一份合同里包含付款安排、交付物和服务等级约定（SLA），它们本质上是不同的业务对象，由不同团队负责：财务跟踪应收款及到账情况，交付团队负责交付物的完成与验收，服务团队负责 SLA 的履行。这些对象通过合同关联起来，“合同管理”才能被拆成可以分配和检查的具体责任。

因此，职能建模可以从现有的部门职责和 JD 开始，把其中的对象、责任和适用范围提取出来，再放回实际业务中校验。

过去，这些定义主要以文本存在。同一项责任可能在不同文档里使用不同名称，同一个“负责”也可能分别意味着执行、协调或最终确认。一份职责说明单独看很完整，几份放在一起，却难以判断边界是否衔接。

将它们放到共同的结构中，才有条件识别责任重叠：多个主体负责的是同一件事，还是分别承担其中不同的部分？

要发现责任真空，还需要沿业务过程检查。所有部门的文档都没有写到的工作，不会仅靠整理文本自动出现。

已有职责是建模的入口，业务能否完整运行是校验的依据。

二、责任要落得准，先要有稳定的业务对象

仅仅把 JD 结构化，还不够。责任所指向的对象，本身也可能没有被明确表达。

传统系统往往按照各自的产品模块和实施范围切分，软件边界未必对应真实的业务边界。一份销售合同可能在 OA 中完成审批，在 ERP 中形成订单，在项目系统中组织交付，后续变更又留在聊天记录和附件中。

现实里连续发生的业务，进入系统后被拆成了几段。它们之间如何对应，哪份信息有效，某次变更影响了什么，经常需要熟悉业务的人补全。

这时，两个部门都说自己“负责合同”，可能指的是不同阶段，也可能指向不同系统里的局部记录。直接比较职责文本，很难判断它们究竟重叠在哪里，又遗漏了什么。

稳定的业务对象，才能为责任提供共同的坐标。

这里的稳定，意味着对象有明确的业务含义，可以被持续指认。同一份合同跨过系统边界后仍然能够对应，其状态、版本和相关业务能够被追踪。合同、订单、交付物和应收款则各有自己的边界，并通过明确的关系连接起来。

对象清楚以后，责任才能落到具体位置：谁维护合同的生效内容，谁跟踪应收款，谁确认交付物已经满足验收条件，以及这些责任如何在变更发生时接续。

因此，对象建模与职能建模需要相互校验。对象边界帮助责任落准；拆解职责时发现的含混，也会反过来暴露业务模型中的缺口。

三、同一个对象，不同职能会推导出不同的系统能力

同一张采购订单，采购人员负责跟进交期和处理到货异常，采购负责人关注整体供应风险、人员分配和超出授权范围的事项。他们管理的是同一个业务对象，但承担的责任、需要的信息和可以执行的动作不同。

对同一个对象的管理权与执行权，可以分别定义，再据此推导视图、消息、权限和审批。 同一个人可以兼任两类职能，系统仍然需要区分他在什么范围内、依据什么授权采取行动。

这种分离不必表现为两套独立系统。订单身份、事实和历史可以共享，不同职能获得各自需要的视图与操作入口。

当职能的责任范围、对象关系、动作权限和业务规则被明确后，其中相当一部分配置就有了计算依据：一个人应该看到哪些订单，某次交期变化应该通知谁，一项调整能否直接执行，超出权限后应该交给谁，都可以沿着这些关系推导。这里能够推导的是信息范围、可用动作、通知对象与流转条件；这些内容如何组织成具体页面和交互，还需要结合使用场景设计。

例如，供应商推迟交期，可以先找到订单对应的采购执行人，再根据受影响的项目识别相关负责人；只有达到约定的升级条件，才进入管理者的待处理范围。普通进度更新、需要执行的任务和需要管理决策的事项，也因此能够分开。

列表、详情、消息、权限和审批，是同一套职能与对象关系在不同使用场景中的展开。 明确这套关系，就有机会减少各系统重复配置、彼此不一致的问题。人或 Agent 承接某项职能时，也能据此获得相应的信息范围、行动权限和协作接口。

四、把业务需要的能力，与当前承担者分开

当职能能够被独立描述，就可以将它与部门、岗位和人员的承担关系分开维护。

例如，企业需要评估订单能否按期交付。这项职能涉及明确的对象、依据和结果：针对客户订单，结合物料到货、生产进度和可用产能，形成预计交期及风险判断。

今天，这项工作可能由某位计划员承担；规模扩大后，可能按产品线分配给不同团队；数据和规则完善的部分，也可能由系统参与完成。承担方式发生变化，企业仍然需要交期评估这项能力。

反过来，一个岗位也往往包含多个职能。一位计划负责人可能既评估交期，又安排生产，还参与重大异常协调。岗位并不是业务天然存在的基本单位，而是特定生产力与组织条件下，对若干职能与责任的组合。若直接以现有岗位定义 Agent 的边界，就等于预先固定旧的分工方式，忽略了职能可能被重新拆分、组合和分配的空间。

职能与承担关系可以分成两个层次：

部门和岗位可以承接、组合这些职能，人员再通过任职及具体业务分工承担职责。从“负责某产品线”到“负责这一张订单”，范围也需要能够继续落实。

这样，组织调整就有了明确的位置。换人时调整承担关系，业务扩张时调整责任范围，工作方式变化时重新组织参与者。业务本身改变，则修订职能定义。

五、让组织分工成为可以检查的业务结构

将这些关系放在一起，就能从两个方向检查组织。

从业务对象出发，可以检查它在形成、变更、履行和结束的过程中，需要哪些责任，这些责任是否已经有人承担，交接是否完整。

从部门、岗位和人员出发，可以检查其承担哪些职能、覆盖什么范围，以及与其他主体之间存在怎样的协作关系。

原本分散在职责文档和个人经验中的分工，由此成为一套可以共同指认和调整的业务结构。AI 可以辅助从现有材料中提取候选定义、比较差异；其中的边界和分配仍需要结合实际业务确认。

在这套结构之上，才可以进一步讨论：职责如何映射为权限，审批节点分别承担什么判断，具体任务如何产生，以及哪些工作适合交给 Agent。

职能模型先明确业务需要围绕哪些对象持续完成什么工作，再通过职责分配明确由谁在什么范围内承担。 把这两个层次分别表达，组织才有基础持续调整分工，并让人、系统和 Agent 承接相应工作。

当这些职能进一步被展开为对象范围、状态条件、行动权限、规则与协作接口时，它们也提供了一种不同于固定 workflow 的工作组织方式。《Agent 不会消灭工作流，它只会逼我们重新理解工作流》继续讨论了这一点：Agent 打破固定执行路径以后，为什么反而需要把这些结构显式定义出来。