AI Worker:从AI助理到AI员工、AI团队与AI组织

让 AI 团队成为组织可积累、可复用、可迁移的数字资产

在《我们为什么做 Teloa》中，我们讨论过一种变化：用户开始把任务的规划与执行交给 AI。能调用工具、加载 Skill（技能）的 Agent（智能体），已经可以完成相当复杂的任务。

当 AI 持续参与同一项业务，人的投入也会变化。业务知识需要整理，专业判断需要变成可用的方法，不同岗位之间还要逐步形成配合。我们做 Teloa，希望这些投入能够留在员工与团队里，随着工作持续改进，也能在更换模型或运行平台时延续。

01｜个人助理背后的专业分工

在会话里，人通常负责组织工作：补充背景、选择材料、判断回答是否可用，再把结果带到下一步。AI 助手进入应用后，开始帮助人处理文档、代码和业务操作；任务 Agent 则能够围绕目标选择工具、执行步骤，并根据反馈继续推进。

个人助理又增加了一种预期：它要持续理解同一个人的目标、项目和偏好，接续以前的工作。Grok Bot 的公开设计已经把有名称、有工作职责、跨会话积累上下文的 Bot 作为产品对象，并支持 Bot 之间协调工作。这些设计让我们看到，持续角色与工作关系正在进入 Agent 产品的中心。

我们的进一步判断是，个人助理可以统一承接需求，再由不同的专业岗位完成具体工作。

做研发需要理解代码与工程约束，做财务需要遵循另一套资料范围和复核要求，安全处置又涉及不同的工具与行动权限。用户可能希望它们保持各自的专业积累，也希望它们围绕同一项业务协作。这里开始出现岗位与团队的需要。

员工与团队适合需要持续分工、专业积累、相互检查和接力交付的工作。简单任务仍然可以由一个 Agent 完成。

随着日常执行逐步交给 AI，人的工作也会改变。原来每次由人完成的比较、检查和交接，需要整理成 AI 可以使用的方法；人根据交付结果继续校准方法，判断异常与重要风险。员工与团队的设计，要能承接这些专业经验，让后续同类工作继续使用。

02｜Prompt、Skill 和 Harness 解决了哪些问题

专业经验要能被 AI 使用，也要便于后续修订。Prompt、Skill 和 Harness 为此提供了不同的基础。

Prompt（提示词）可以交代角色、目标和要求。但如果每次都把方法、参考资料、示例和操作细节重新写进提示词，专业能力很难独立维护，也很难被其他工作复用。

Skill 把其中一部分知识和做法组织成可发现、可加载的能力包。Anthropic 对 Agent Skills 的设计就包括说明、脚本与资源，让通用 Agent 能按需使用专业方法。专业方法可以单独维护，并供不同员工与团队使用。

Harness（执行运行时）负责把任务运行下去。一项复杂工作可能调用多次模型和工具，也可能跨越多个会话；运行时需要保存进度和必要的上下文，让下一次运行知道从哪里继续。长时间运行 Agent 的工程实践说明了这一点：后续会话需要知道以前做了什么、哪些工作仍未完成，以及怎样继续验证结果。

这些基础使 Agent 能够执行复杂任务。要让它承担长期岗位，还要明确持续身份、职责、工作安排与团队关系。

例如，一项报表分析 Skill 可以被财务员工、运营员工和个人助理使用。每月的经营分析还要确定由谁承担、采用哪份业务口径、谁复核，以及结果交给谁。这些约定由岗位与团队维护，Harness 负责具体分析任务的运行。

因此，我们希望把可调用的能力组织成能够持续负责的岗位：保留必要的背景与经验，按岗位安排例行工作，遇到新问题能够继续判断或交接。任务结束后，相关经验留在对应的员工或团队中，岗位职责和例行安排也继续保留。

03｜一位 AI 员工由什么组成

设计 AI 员工时，我们从持续职责出发。它负责哪一类工作，在什么情况下接手，怎样判断结果，什么时候需要人介入。这些约定让用户可以把后续同类工作继续交给它。

以前面的经营分析为例，一位员工持续负责解释经营变化。它接收获准的经营数据，按约定口径完成比较，交付包含结论、证据和待确认问题的分析，并把无法核实的异常交给负责人复核。

用户还可以为这项工作安排按月执行的例行计划。每轮分析使用本期数据，同时带入已确认的指标口径、解释偏好和上期仍待核对的问题。交付经过检查后，确认的判断与经验按来源和适用范围保留，供下一轮继续使用。用户不必每个月重新教一遍同样的工作，分析中得到的改进也能随这个岗位保留下来。

提炼专业经验，要写清做法、判断依据、适用条件、异常处理和合格结果。人据此检查 AI 是否沿用了原有的专业判断，并根据分析过程与结论继续改进方法。

围绕这项职责，Teloa 用七类属性描述员工：Role（岗位职责）、Identity（身份）、Knowledge（知识）、Skills（技能）、Tools（工具）、Memory（记忆）和 Permissions（权限）。

Role（岗位职责）说明承担什么工作，Identity（身份）让不同任务仍能归属于同一位员工。Knowledge（知识）提供业务事实和依据，Skills（技能）提供可复用的方法，Tools（工具）提供行动能力。Memory（记忆）保留有来源、有适用范围的经验与背景，Permissions（权限）决定这些能力在什么授权下可以使用。

SOP（标准作业程序）则把方法放进工作的安排里。一个分析 Skill 可以说明怎样比较数据，SOP 要进一步说明先取得哪份材料、在哪些节点复核、什么情况下交给其他岗位。具体任务再确定本次输入、成果与验收要求。

SOP 可以随 Skill 分发，也可以由 Harness 组织执行。其中的材料要求、检查节点和交接负责人应当写清楚，让执行者知道每一步怎样继续。

图 1｜七类员工属性与 SOP、岗位工作、例行安排及运行基础的关系。资源按具体工作启用。

业务知识、专业方法和岗位规则按各自的变化节奏维护。更新资料、改进分析方法时，员工的身份和职责可以延续；临时要求在本次任务内生效，并保存在任务记录中。

岗位模板说明这类员工负责什么、怎样工作。同一模板可以创建多位员工，每位员工分别保留身份、经验和工作记录。员工每次执行任务，都记录当时使用的模板版本、资料、授权和成果。以后更新模板或更换模型，仍能查清旧任务是依据什么完成的。

同一种 Agent 技术可以用于临时任务，也可以承载长期岗位。长期岗位由产品维护持续身份、职责、资源关系与工作积累。

04｜AI 团队的组成与协作

多位员工共同参与工作时，需要对齐资料、安排先后并汇总成果。这些协调工作可以由团队统一安排。

用户应该能够把一项版本交付交给团队，由团队明确需要哪些输入、交付什么成果、怎样验收。这要求团队维护成员分工、共享的业务依据、交接方式与共同成果。团队也有自己的方法、知识和经验，由成员按工作需要共同使用。

以软件版本交付这一设计场景为例。开发员工负责实现变更，测试员工验证行为，文档员工解释用户需要知道的变化。三位员工各自掌握代码修改、测试或写作 Skill，但团队还需要共同的版本范围、验收要求、变更资料和发布安排。

代码有了新修订，测试要知道自己验证的是哪一版；文档需要区分已经进入版本的变化和仍在讨论的方案；负责人要拿到一份能对上相同版本的交付结果。

SOP 确定哪些工作可以并行，哪些依赖前一份成果，什么条件下补查或退回。成员使用共同确认的版本范围和变更资料。交接时带上成果对应的代码版本、依据的资料和待办事项，下一位成员就知道从哪一步接手。

团队还需要共同的工作状态与经验：谁正在负责、哪些问题待查、哪些决定已经确认，以及哪些结论后来被修正。项目记忆保存这个项目的背景与决定，成员继续交付时可以带入相关资料和待办；岗位经验保存经过检查的专业做法，供员工以后承担同类工作时使用。每项记录保留来源和适用范围，让接手者知道哪些信息适用于眼前的任务。

例如，某次交付发现测试遗漏，经过复核，团队把补查方法加入 SOP，后续版本继续使用这项改进。留下来的除了代码和报告，还有团队怎样避免同类问题的经验。

团队根据成员的职责分配权限，明确每位成员可以访问的资料、使用的工具和执行的操作，由执行环境落实授权。

图 2｜软件版本交付的组织设计示意。研发与安全团队各有专业分工、共享资源和工作规程；业务负责人处理跨团队风险与发布决定。图中表示组成关系，不限定执行顺序或固定组织层级。

平台依据这些约定组织并行、接力与独立复核。成员负责各自的判断与产出，人处理必要的目标调整、授权和业务决定。

05｜多支团队之间，为什么还需要组织

当研发、安全、运营等团队开始共同服务一项业务，问题会进一步变化。

某套知识可能供多个团队引用，一个专业员工可能参与多支团队，一项公共资源可能有统一预算。团队自行安排日常工作，影响其他团队的变更由共同的决策规则处理。

继续看这次版本交付。研发团队已经准备发布，安全团队还有一项高风险问题没有查清。双方的专业判断为业务决定提供依据，是否按期发布、能接受多大风险、要不要调整调查优先级，由有权承担业务责任的人决定。

我们由此推演 AI Organization（AI 组织）的组成：它组合员工与团队，也维护共同目标、资源、权限策略、预算约束和决策责任。团队约定怎样共同交付，组织进一步明确跨团队决定由谁作出、依据什么规则，以及怎样安排受影响的工作。

一支团队也可以作为整体参加更大的项目。业务负责人交给研发团队一个版本目标，团队自行安排开发、测试和文档，按约定交出经过验证的版本。交付范围、权限和验收要求由双方事先约定，团队内部可以继续改进分工。

组织需要划分团队自主决定和共同决定的范围。过度集中会拖慢日常工作，完全交给局部决定又容易影响其他团队依赖的安排。改变分工或工作要求时，还要说明已经开始的任务按哪套安排继续，并保留旧成果的形成记录。

组织长期投入形成的，是一支越来越懂业务、能够协作的数字团队。岗位职责、业务知识、技能与 SOP、持续记忆、经过检验的经验，以及任务、文件、成果和协作关系，都应成为组织能够拥有和掌控的数字资产。团队调整分工或成员时，这些积累仍应留下来。

这也是 Teloa 的一项设计原则：AI 团队资产应当属于用户，并能随着用户的选择自由迁移。模型可以升级，Harness 可以更换，部署位置与算力可以调整，长期积累的员工和团队资产应当延续。组织可以根据业务、能力、成本和数据要求选择执行环境，无需为每次技术更替重新建立一支团队。

要做到这一点，员工和团队的定义、知识与经验、工作记录，需要与模型及运行环境分开维护。迁移也要保留这些资产之间的关系：经验适用于什么工作，成果依据哪个版本形成，谁负责下一步。

06｜为什么要公开这些工作定义

以这支版本交付团队为例。组织选择另一个运行平台时，代码和报告可以复制过去，接收方还需要理解测试对应哪次代码修订、哪些问题尚待复核、下一步由谁负责。前面补入 SOP 的测试方法，以及已经确认的项目决定，也需要继续参与后续交付。

这要求产品按资料范围保存、导出和恢复既有知识、记忆、工作记录与成果，保留它们的来源、版本和归属。共同定义说明每位员工负责什么、使用哪些资料和技能、成果交给谁，接收平台据此安排后续工作。

工作关系采用各平台的私有表达时，迁移要逐项解释与转换。我们选择把工作定义公开，让不同参与方能够以同一份规范为依据保存、解释和实现它们。规范公开岗位职责、所需资料与能力、工作输入与成果，以及成员怎样交接。组织自己的业务资料和账号凭据仍由组织管理。

共同定义也使方法分享更容易。行业作者可以分享一套版本交付团队的定义，其他组织采用其中的岗位、SOP 和协作方法，再接入自己的资料与授权。经过实践改进的方法，也可以继续供同行复用。

已有协议正在解决其中不同部分。MCP提供 AI 应用连接外部工具与数据的方式；A2A已经定义 Agent 交互中的能力描述、任务状态、消息与成果。Skill 格式让专业方法可以打包和加载。这些工作是可以利用的基础。

AI Worker 标准统一描述 AI Worker（AI 工作者）、AI Team（AI 团队）与 AI Organization（AI 组织）。三者都要写清接收什么工作、交出什么成果、需要哪些资源，以及由谁检查结果。

员工说明职责和工作方法，团队说明成员如何分工、共享资料和交接，组织说明跨团队决策与资源分配。工具接入和 Agent 通信可以采用已有协议，运行平台负责把这些安排落实为实际执行。

迁入新平台时，要接入所需资料和工具，确认每位成员的权限，并按原有要求检查交付。例如，原团队要求独立复核，新平台就要安排相应的复核者；条件不足时，应说明缺什么、哪些工作暂时无法继续。共同定义让双方可以逐项对照这些要求。

AI Worker 开放定义标准 1.0 由 Max Luo 与 Morgan Chen 共同发起，Teloa 维护，采用 Apache-2.0 许可。

我们希望通过这套标准，将组织沉淀的岗位定义、知识、技能与 SOP、记忆和协作关系，作为业务面独立维护，与模型、Harness 和部署环境等 Agent 基础设施解耦。底层技术持续演进，组织仍能掌控自己的 AI 团队资产，并按业务需要复用和迁移。

点击文末“阅读原文”，查看规范、组成图解和完整示例。

开源地址：

https://github.com/teloa-ai/ai-worker-standard