上一篇停在"让下一个 Agent 少猜一点"。我给个人用 Agent 的方式立了面镜子——会话检索、工作画像、运行时投影，一圈下来，至少能让下一个 Agent 接手时少磨合几轮。
但真往企业走，对象就变了。不是一个人调 Agent，是一个组织要把"数字员工"纳进来。那时候要回答的，不再是"我的习惯是什么"，而是"它是谁、归谁管、干什么活、出了事谁兜"。
一、别急着选模型，先想清楚它是谁
企业里谈数字员工，第一句多半是"它能不能干这个、能不能干那个"。能力挂嘴边，模型先选起来。
但我把这周的设想画成图之后，越画越觉得：企业里第一个要回答的问题，不是它能不能干，是它到底是谁。
这跟招人一个道理。你招个新员工，第一件事不是问他会不会某门技术，是确认他的身份——叫什么、归哪个部门、谁是他主管、出事找谁。数字员工进了企业，这些问题一个都躲不掉。
所以这张图最里层，是四个身份对象，不是一张脸。
AE：真实员工。有固定工号，能归属多个部门和岗位。团队负责人必须是 AE——这条规则看着简单，背后是企业治理的底线，出事得有真人兜。
DEP：数字员工画像。这是能力定义层，是数字员工的"类"。一个画像定义了它能干什么、边界在哪。
DE：数字员工。稳定身份，有固定工号，属于岗位或部门，不属于某个个人或团队。它跟 AE 一样，是企业里正式的一号人。
DEC：数字员工克隆。基于 DEP 创建，有临时工号，不可复用，必须挂一个 AE 当负责人。
这里头最值得说的，是 DEP 和 DE/DEC 的分离。画像是能力定义，数字员工和克隆是运行实例。这跟软件里"类→对象→临时实例"是一个思路——但企业场景给它加了一条硬规矩：临时实例（DEC）不可复用，而且必须有真人负责人。
为什么 DEC 必须挂 AE 负责人？因为克隆是临时的、是跑某次具体活的。活干完了，克隆该销毁。但销毁之前，它干的每一件事，得能找到一个真人兜底。没有负责人的克隆，就是脱缰的。
把身份先定义清楚，后面所有的委派、执行、审计，才有挂靠的地方。不然你连"谁干的"都说不清，谈什么追溯。
二、团队负责人必须是真人
这条规则我单独拎出来讲，因为它便宜又关键。
数字员工能进团队，但不能当负责人。一个团队的架构主轴和协作单元，成员可以包含 AE、DE、DEC，但负责人只能是 AE，且可转移。
为什么这么较真？因为企业治理的底层逻辑是——责任必须落到一个能被问责的自然人身上。数字员工可以干活，但它承担不了责任。一个团队如果负责人是数字员工，出了事故、出了合规问题，你问责问谁去？问那个模型？
这不是保守，是被现实逼出来的设计。我见过太多"AI 自主执行、出了事算谁的"的扯皮场景，最后都是因为没有在最早的设计里把责任锚点钉死。
钉死了这个锚点，数字员工在团队里的位置就清楚了：它是干活的成员，不是担责的负责人。个人用 Agent 的场景，也用"一人团队"统一掉——别给个人用法留一套特殊结构，结构越统一，越不容易乱。
三、一项活从委派到复核，得能追
身份立住了，接下来是一件事怎么从头到尾跑完。
我把数字员工进入团队工作的核心过程拆成六步：引入、任用、委派、协作、交付、治理。听起来像 HR 的入职流程——确实像。因为数字员工要真进团队，就得按真员工的流程走一遍，只是每一步的内容不一样。
但这六步只是用户能感知的表面。底下还有一条运行时协议链路，才是能不能追的关键：
触发源 → 投递单 → 执行尝试 → 运行时
这条链路里，有一个判断我特别在意：回复、副作用、产物，必须分开理解。
Agent 给你回了一段话，那是回复。它实际改了什么文件、调了什么接口，那是副作用。它最后留下了什么可复用的东西，那是产物。这三者不是一回事。
很多翻车就翻在这里——Agent 回了一段漂亮的总结，人以为活干完了，结果副作用没落地，或者产物根本没留下。把三者分开，是数字员工能被复核的前提：你不能拿回复当结果，也不能拿副作用当交付。
这一点跟上篇是一脉相承的。上篇做的是个人会话的可观测——追溯"我说过什么、Agent 干过什么"。这篇做的是企业数字员工的可追溯——每个动作从触发到投递到执行到运行时，每一段都要留痕。镜子从照个人，变成了照团队；但"能追"这件事，没变。
四、能力是评审出来的，不是拍脑袋
身份、责任、流程都想清楚了，下一层问题：数字员工到底该有哪些能力？
最容易的做法，是列一张能力清单——身份、委派、执行、协作、权限……凑个八大类，往文档里一摆，看着挺全。但全不代表对。这跟上篇踩过的那个坑一样：做过不等于擅长，列了不等于成立。
所以这次我给能力评审立了规矩。八项候选能力摆出来，但评审完有四种结果：
- 保留：进产品范围，作为核心或企业准入能力。
- 合并或下沉：不单独占一个坑，并进别的能力，或者作为子能力。
- 转为横切要求：不独立成项，但贯穿所有能力——比如治理、安全、可观测性。
- 延后或移除：价值或证据不够，暂不建设。
换句话说，候选能力不等于最终能力。摆出来是为了审，不是为了全做。
审的时候，每项能力过八个维度：谁在什么场景需要它、少了它核心闭环还成不成立、市场有没有更简单的替代、企业准入过不过、证据够不够。八个维度问下来，一项能力该不该留、该不该现在做，基本清楚了。
这里还有一条我学乖了的：论证记录要同时留支持证据和反例。哪条事实支持它、哪个场景不需要它、有什么更简单的替代——都记着。别只收集支持当前方案的信息，那是自欺欺人。
方案依据我分了六级，标在每条结论旁边：
| 依据 | 含义 |
|---|---|
| Fact | 可由文档、代码、测试直接确认的外部事实 |
| Constraint | 客户、法规、预算给的硬边界 |
| Validated | 经过访谈、原型、PoC 验证过的 |
| Inferred | 从已知约束推出的，逻辑成立但还没验 |
| Hypothesis | 值得验证的方向，必须说明怎么验、失败信号是什么 |
| Consideration | 团队经验或偏好，需要结合其他依据综合评 |
哪条是事实，哪条是假设，哪条只是我们的偏好——白纸黑字标清楚。这东西不讨巧，报告会少很多斩钉截铁的结论。但心里踏实：至少能告诉我一条结论凭什么暂时成立，又会在什么情况下失效。
五、什么自研，什么买，什么用开源
最后是建设层。能力评审完了，每项能力从哪来——自研、开源、商业，得分清楚。这里最容易踩的坑是两个极端：什么都自研，或者什么都外包。
我把推导过程拆成六层，自上而下不颠倒：
业务价值与约束
→ 产品能力
→ 产品与领域模型
→ 系统职责与逻辑架构
→ 能力来源与投资选择
→ 物理实现与运行验证
为什么要强调不颠倒？因为见过太多团队倒着来——先选了技术栈、先买了某个商业产品，再回头硬把业务往里塞。业务服务于技术，最后必然拧巴。自上而下，意思是技术方案承接产品能力，产品能力服务业务目标，谁也别替谁做决定。
落到能力来源上，我的判断是这样的：
- 数字员工、Team、任务与交付语义——核心自有。这构成产品心智和治理边界，是长期数据资产的锚，不能外包。
- Delivery/路由/审计控制——自研薄层。统一不同 Runtime 的控制和审计语义，要薄但要有。
- Agent Runtime 与模型推理——商业合作。成熟能力，重点管价格、合规和供应商依赖，别自己重造轮子。
- Sandbox 执行环境——采用开源。复用隔离和生命周期能力，但接口保持可替换。
- 身份认证与授权——自有策略 + 企业身份源。产品掌握授权语义，认证对接企业 IAM。
一句话总结这条原则：掌握产品核心语义，基础能力优先采用成熟方案。
这里有个容易混的点要单独说：Runtime 和 Sandbox。有些 Agent Runtime 产品会集成 Sandbox，但两者职责不同。Runtime 管 agent loop、上下文、工具调用、执行协调；Sandbox 管隔离、资源、执行环境生命周期。采购可以一体评估，但架构和替换边界要分开管理——不然哪天想换 Sandbox，发现它跟 Runtime 绞在一起，拔不出来。
六、写在最后
从上一篇的"找回散落的会话"，到这一篇的"数字员工入团队"，其实是同一条线：都是把散落的东西结构化、可追溯。
上篇是给个人用 Agent 的方式立镜子——会话能搜、画像能查、证据能回溯。这篇是给企业的数字员工立规矩——身份要分清、责任要钉死、流程要能追、能力要审、来源要分。
两篇合起来，我心里有个更朴素的东西在起作用：一个对象要真进生产环境，不管它是个人习惯还是企业员工，都得先把它"说清楚"。说清楚它是什么、归谁、干什么、怎么追。说不清的东西，越聪明越危险。
这套可视化不敢说全对，它还是 v0.1、v0.2 的阶段方案，很多判断还得靠访谈、原型和试点去校准。但至少，它把"数字员工"从一个热词，落成了一组可以逐条审的对象。
把数字员工当真员工招，最难的不是它够不够聪明，是身份和责任这种不性感的事。但偏偏是这些事，决定了它能不能在企业里站着。