> ## Documentation Index
> Fetch the complete documentation index at: https://opc-43d279b8.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 硅基员工：把 Agent 建成一个可考核的岗位

> 硅基员工的判定标准、岗位建模、权限与审计、生命周期，以及 ROI 与治理的面试要点。

> 我更喜欢用"岗位"而不是"功能"来设计 Agent：交付物、验收标准、权限边界、异常升级，这四样定下来，它才像个员工。

***

## 1. 定义：什么才算"硅基员工"

先给一个可操作的判定标准。满足以下五条，才配叫硅基员工；缺一条，它就还是工具、脚本或 Copilot。

| 判定项 | 必须回答的问题 | 不满足时的真实形态 |
| - | - | - |
| 岗位责任 | 它对哪一段流程的什么结果负责？ | 一次性问答工具 |
| 端到端交付 | 它交付的是可验收产物，还是"建议"？ | 写作助手 / 搜索助手 |
| 可考核 | 有合格率、时效、成本、风险指标吗？ | Demo |
| 身份与权限 | 它代表谁、能读写什么、什么必须审批？ | 共享账号脚本 |
| 异常升级 | 失败、越权、低置信度时找谁？ | 报错即终止的 RPA |

### 1.1 与 RPA、Workflow、Copilot 的边界

| 形态 | 执行依据 | 异常处理 | 交付物 | 适用场景 | 典型失败 |
| - | - | - | - | - | - |
| RPA | 固定脚本、界面坐标 | 基本没有，界面一变就断 | 动作完成 | 规则极稳定、系统无 API | 变更即崩 |
| Workflow | 预定义 DAG、代码路由 | 有限重试、人工工单 | 流程走完 | 步骤清晰、分支可枚举 | 长尾例外覆盖不了 |
| Copilot | 人的实时指令 | 人兜底 | 草稿、建议 | 辅助写作、编码、分析 | 人不在就不工作 |
| 硅基员工 | 目标 + SOP + 工具 + 判断 | 重试、降级、人工接管、补偿 | 可验收成品 | 规则清晰但有长尾异常、结果可验证 | 责任不清、权限失控 |

关键差别不在"能不能调用工具"，而在**谁对最终结果负责**。RPA 对"动作执行"负责，Workflow 对"路径走完"负责，硅基员工对"结果合格"负责。

### 1.2 不是所有岗位都值得硅基化

用六个维度打分，每项 0-2 分，总分 12 分。低于 7 分先别做"员工"，做 Copilot 或 Workflow 更划算。

| 维度 | 0 分 | 1 分 | 2 分 |
| - | - | - | - |
| 规则清晰度 | 大量靠临场判断 | 有 SOP 但例外多 | SOP 明确、边界清楚 |
| 数据可得性 | 数据散落、无接口 | 部分系统可接 | 数据完整、接口稳定 |
| 结果可验证 | 好坏靠主观 | 可抽检 | 有明确验收标准 |
| 异常长尾 | 例外占比高 | 中等 | 长尾可控、可升级 |
| 协作密度 | 需要大量跨部门谈判 | 少量协作 | 单人/单岗可闭环 |
| 合规敏感度 | 高风险、强监管 | 中等 | 低风险、可审计 |

> 经验值：信贷材料初审、日报生成、标准化设计、合同条款比对适合先做；战略规划、危机公关、复杂并购谈判不适合直接做成"员工"。

> [!NOTE]
>
> 硅基员工 = 岗位责任 + 端到端交付 + 可考核 + 最小权限 + 异常升级。没有这五件套，它只是一个更贵的聊天框。

***

## 2. 公开案例查证：WorkBuddy 及企业实践

### 2.1 先立规矩：怎么引用案例才不算"把宣传当事实"

企业服务案例普遍存在三层信息：**官方发布/产品文档**、**媒体转述**、**客户或合作方口径**。写面试答案时，最好明确说"公开资料显示""公司口径称""第三方数据称"，不要把厂商的"提升 80%"说成行业共识。

| 证据等级 | 含义 | 可以怎么用 | 不能怎么用 |
| - | - | - | - |
| A. 产品文档/上市公司公告 | 可复核的功能、价格、交付形态 | 说明产品边界与机制 | 不能证明客户效果 |
| B. 主流媒体/政府网站转述 | 有记者、有时间、有出处 | 说明"某企业公开宣称" | 不能当成独立测评 |
| C. 厂商案例/活动通稿 | 客户故事、合作方口径 | 说明落地方式与场景 | 不能证明普遍 ROI |

### 2.2 WorkBuddy：它到底是什么

公开资料显示，WorkBuddy 是腾讯云 CodeBuddy 团队推出的**桌面 AI 智能体工作台**，2026 年上半年上线，2026 年 6 月 5 日发布企业版 WorkBuddy Enterprise 及办公智能体套件 Agent Suite。它的定位是"一句话下达任务、自主规划多步骤、交付可验收结果"的办公智能体，已经超出"会聊天的助手"的范畴。

| 维度 | 公开信息 | 证据等级 | 怎么理解 |
| - | - | - | - |
| 产品形态 | 桌面工作台 + 企业版 + 云端托管 Agent | A | 个人入口与企业运行底座分开 |
| 核心能力 | 文档/表格/PPT、数据分析、深度研究、本地授权文件处理、多 Agent 并行 | A | 偏办公与知识工作，不是核心交易系统 |
| 企业版三件套 | 7×24 专家数字员工、人与 AI 协作的"项目"、企业管理后台 | A/B | 对应岗位、协作、治理三层 |
| 专家机制 | 专家 = "人设 + 方法论 + 工具链"的角色切换；专家团 = 团长拆解、并行执行、整合交付 | A | 产品已把"专家团"产品化 |
| 权限边界 | 专家本身不主动获取系统权限，只处理用户主动提供的对话与文件；配 Skill/MCP 后才在授权下访问外部服务 | A | 权限按用户授权收敛，Agent 不自带权限 |
| 企业管理 | 专家分类、可见范围、下发策略、调用统计、批量启停、内置专家先审后用 | A | 已具备"AI 资产治理"雏形 |
| 安全 | 沙盒隔离、技能标准化、危险操作拦截、操作审计 | A/B | 桌面 Agent 的必备防线 |
| 规模数据 | 截至 2026 年 6 月服务 1000 余家企业；2026 年 6 月月访问量 2097 万 | C | 合作方/活动通稿口径，未经独立审计 |

**能力边界要讲清楚：**

1. **能做什么**：办公文档、数据分析、报告/PPT、授权文件夹整理、跨应用操作、专家团并行推进。适合"知识工作 + 多步骤 + 可验收产物"。
2. **不能做什么**：不能替代核心业务系统的事务一致性；不能在没有连接器和授权的情况下访问企业系统；不能为"数字员工"三个字承担法律责任；也不能证明所有客户都获得了同等人效提升。
3. **值得注意的产品信号**：WorkBuddy 企业版把"数字员工、项目、管理后台"放在一起。这至少说明该厂商在往"岗位 + 协作 + 治理"的形态上走；是否构成行业转向，还要看其他主流厂商是否跟进。

### 2.3 其他公开案例：能验证什么、不能验证什么

| 企业/机构 | 公开场景 | 公开要点 | 证据边界 |
| - | - | - | - |
| TCL 华星 | 显示研发设计全流程 | 2026 年 11 月 13 日发布"硅基员工"，融合大模型、多智能体与工程工具，打通方案策划、设计、仿真、验证、品质管理；公司称客户需求响应速度提升 80%、仿真规模可达原来的数十倍 | 上市公司子公司 + 媒体转述；80% 等数字为公司口径，未见独立审计 |
| 酷开科技 | 企业 AI 操作系统 | Happy Work AIOS 提出企业/岗位/个人/任务四层智能体；强调人机共驾、业务域数据隔离 | 厂商发布 + 媒体转述；内部效果无公开量化 |
| 永洪科技 | 数据分析与智能办公 | vividime Friday 内置八大场景；Polaris 平台以企业本体统一指标口径，模型不持有数据账号、权限按人授权、全程可审计 | 厂商产品说明 + 政府网站转述；架构机制可参考，效果需自证 |
| 上交大苏州智研院/上交致微 | 银行信贷、合规、质检 | "硅基员工工作台"以 Wiki RAG 做知识网络检索，用 Skills 经验蒸馏固化专家经验；称已在苏州农商行、常熟农商行、江苏农商联合银行、湖州银行等落地 | 项目团队 + 媒体转述；"检索准确率接近 100%"属团队在开源数据集上的口径，需谨慎 |
| 科大讯飞 WinWork | 政企专业岗位 | 提出"先培训、再考核、后上岗"的数字员工工厂；用 AI Connection 接存量系统；覆盖创建到回收的全生命周期 | 厂商发布会 + 媒体转述；生命周期方法可借鉴 |

> [!WARNING]
>
> 不要说"某产品已经证明硅基员工能替代人"。更准确的表达是："公开资料显示，某企业在某类规则清晰、数据密集、结果可验证的岗位上做了岗位化尝试，厂商/企业宣称了某类效果；这说明了可行路径，但不等于行业已经成熟。"

***

## 3. 岗位建模：把一个岗位拆成 Agent 可执行的任务图

### 3.1 先写"岗位说明书"，再写 Prompt

| 字段 | 要写清楚什么 | 反例 |
| - | - | - |
| 岗位名称 | 对什么结果负责 | "AI 助手" |
| 职责范围 | 从哪个触发到哪个交付 | "帮忙处理信贷" |
| 明确不做 | 哪些判断必须交给人 | 不写边界 |
| 输入 | 单据、系统、字段、时效 | "相关材料" |
| 输出 | 产物格式、字段、口径 | "给个结论" |
| KPI | 合格率、时效、成本、风险 | "提效" |
| SLA | 正常/高峰/异常时限 | 不写时限 |
| 升级路径 | 什么情况找谁、多久响应 | 出错再说 |
| 人机分工 | 哪些 AI 做、哪些人做、哪些共同做 | 全自动或全人工 |

### 3.2 五步拆解法

```text theme={null}
① 切价值流：从"业务触发"到"结果交付"画一条端到端链路
② 列任务：把链路拆成动词短语，标注频率、耗时、例外率
③ 判可自动化：规则清晰度 × 数据可得性 × 结果可验证性
④ 画任务图：触发 → 取数 → 判断 → 生成 → 校验 → 审批 → 交付 → 归档
⑤ 定人机边界：哪些节点自动、哪些建议、哪些必须人工签字
```

拆解时最容易犯的错，是**按部门拆而不是按价值流拆**。按部门拆会得到"财务 Agent、法务 Agent、风控 Agent"这种组织镜像，但真正要交付的是"一笔信贷从材料到放款"或"一份日报从取数到发布"。硅基员工应该对价值流负责，部门只是权限和知识的来源。

### 3.3 任务节点契约

每个任务节点都要有可执行的契约，而不是一句自然语言。

```typescript theme={null}
interface TaskNode {
  id: string;
  goal: string; // 这个节点要产出什么
  inputs: string[]; // 文件、字段、上游产物
  tools: string[]; // 允许调用的工具/接口
  permissions: string[]; // 最小权限，按人授权
  acceptance: string[]; // 可逐条检查的验收标准
  timeoutMs: number;
  retry: { max: number; backoff: string };
  onLowConfidence: "review" | "escalate" | "stop";
  escalateTo: string; // 岗位/角色，不是某个具体人
  costBudget: number;
  outputSchema: string; // 产物 schema 或模板
}
```

### 3.4 KPI 设计：结果、过程、风险三层

| 层级 | 指标示例 | 作用 | 被刷指标的风险 |
| - | - | - | - |
| 结果 | 合格交付率、一次通过率、返工率 | 证明有没有用 | 只挑简单单子 |
| 过程 | 平均交付时长、人工接管率、工具成功率 | 定位瓶颈 | 为了快而跳过校验 |
| 风险 | 越权拦截数、审计缺口、投诉率、合规驳回率 | 防止负向优化 | 把风险藏起来 |

KPI 必须成对出现：**效率指标 + 质量指标 + 风险护栏**。只考核"处理量"，Agent 会学会批量产出垃圾；只考核"准确率"，Agent 会学会只接简单任务。

### 3.5 人机分工的四种模式

| 模式 | 谁执行 | 谁决策 | 适合 |
| - | - | - | - |
| AI 执行、人验收 | Agent | 人 | 文档初审、日报、标准化设计 |
| AI 建议、人决策 | Agent 出方案 | 人 | 信贷审批、投研结论、招聘 |
| 人执行、AI 校验 | 人 | 人 | 高风险操作、对外沟通 |
| 人机并行竞标 | 双方独立做 | 人择优 | 创意、方案设计、复杂分析 |

***

## 4. 技术架构：一个能上岗的硅基员工需要什么底座

```text theme={null}
┌─────────────────────────────────────────────────────┐
│ 岗位层：职责 / SOP / KPI / SLA / 升级路径             │
├─────────────────────────────────────────────────────┤
│ 执行层：任务图 / 规划 / 工具调用 / 校验 / 交付         │
├─────────────────────────────────────────────────────┤
│ 能力层：知识 / 口径 / 记忆 / 技能 / 连接器             │
├─────────────────────────────────────────────────────┤
│ 治理层：身份 / 权限 / 审批 / 审计 / 计费 / 多租户       │
├─────────────────────────────────────────────────────┤
│ 运行层：模型路由 / 沙箱 / 长任务 / 可观测 / 成本控制    │
└─────────────────────────────────────────────────────┘
```

### 4.1 身份与组织架构

* **双身份**：Agent 有自己的身份（工号、所属岗位、版本），同时以"代表某个真人"的方式执行。任何写操作都要能追溯到具体的人。
* **组织同步**：从 HR/IAM 同步部门、岗位、汇报关系；人转岗或离职时，Agent 的权限随之回收。
* **服务账号隔离**：Agent 不共享人的账号，也不共享超级账号；用受控的服务身份 + 代表用户令牌（on-behalf-of）。
* **租户隔离**：多租户场景下，知识、记忆、向量库、日志、计费都要按租户隔离，不能只靠一个 `tenant_id` 字段。

### 4.2 权限模型：按人授权、最小权限、临时授权

| 机制 | 做法 | 解决的问题 |
| - | - | - |
| 按人授权 | 用户能看的，Agent 才能看；用户不能看的，Agent 也拿不到 | 权限放大 |
| 最小权限 | 按任务节点授予工具、字段、行级权限 | 过度授权 |
| 临时授权（JIT） | 高风险操作按次申请、限时、限范围 | 永久授权 |
| 二次鉴权 | 每次读写由资源层再校验，而不是只信模型 | 模型越权 |
| 审批流 | 金额、对外发送、数据导出等触发人工审批 | 高风险动作 |
| 可撤销 | 授权可见、可收回、到期自动失效 | 权限沉淀 |

永洪公开的架构思路值得借鉴：**模型不持有数据账号，权限按人授权，每次读写当场鉴权，数据不出企业、全程可审计。** 相比"给模型一个长期有效的数据库连接"，它把权限收敛到单次操作，暴露面小得多。

### 4.3 知识与口径

* **企业本体**：对象、关系、指标、规则统一定义，避免"同名不同义"。
* **指标层**：销售额、客户、逾期等口径只定义一次，Agent 回答时引用同一份定义。
* **SOP 与制度**：版本化、带生效时间、带适用范围。
* **知识新鲜度**：每条知识有来源、更新时间、负责人；过期知识要降权或下线。
* **冲突检测**：同一问题出现互相矛盾的知识时，不能靠模型"综合一下"，要标记冲突并升级。
* **引用与下钻**：结论要能回到原文、原始单据或指标定义。

### 4.4 记忆分层

| 记忆层 | 存什么 | 生命周期 | 访问控制 |
| - | - | - | - |
| 会话记忆 | 当前任务上下文 | 任务结束即丢弃或摘要 | 仅当前会话 |
| 任务记忆 | 中间产物、决策、未完成事项 | 任务周期 + 保留期 | 任务参与方 |
| 岗位记忆 | 岗位偏好、常见例外、历史处理 | 长期，定期复盘 | 岗位 + 管理员 |
| 组织记忆 | 制度、口径、案例、经验 | 长期，版本化 | 按部门/角色 |

原则：**记忆可查看、可修改、可删除、可追溯来源。** 没有这三个"可"，员工不会信任它，合规也不会放过它。

### 4.5 技能与工具

* **技能注册表**：每个 Skill 有名称、输入输出、权限、版本、负责人、评测集。
* **连接器**：MCP/API/数据库/文件系统，统一 schema，统一超时与重试。
* **沙箱**：代码执行、文件处理、浏览器操作在隔离环境里跑，危险操作拦截。
* **幂等与补偿**：写操作要有幂等键；失败要能回滚或补偿，不能"重试三次转出三笔钱"。
* **Dry-run**：高风险动作先演练，输出影响面，再让人确认。

### 4.6 审批流

按风险分级，而不是所有事都审批：

| 风险等级 | 例子 | 控制 |
| - | - | - |
| 低 | 查数、生成草稿、内部检索 | 自动执行 + 留痕 |
| 中 | 对外发送、修改业务单据 | 单人审批 + 抽检 |
| 高 | 放款、付款、删除数据、权限变更 | 双人复核 + 二次鉴权 |
| 极高 | 合规敏感、跨境数据、重大合同 | 人工主导，Agent 只做辅助 |

### 4.7 审计与回放

一条合格的审计链至少包含：**谁发起、Agent 是谁、用了哪个模型和 Prompt 版本、检索了哪些知识、调用了哪些工具、参数是什么、谁审批、产物是什么、花了多少钱、耗时多少。** 没有这些，"模型自己决定的"就会成为事故后的万能甩锅话术。

### 4.8 长任务与成本

长任务失败多半出在工程上：上下文撑爆、跑一半忘了目标、死胡同里打转、一次查回大结果直接崩，模型能力往往不是主因。可用的工程手段包括：

* **渐进式披露**：先给目录，用到哪页取哪页，不一次塞满上下文。
* **进展检测**：每轮检查有没有推进，没推进就换路或升级。
* **上下文压缩**：已完成步骤压成摘要，保留结论和未决问题。
* **工具结果落盘**：大结果写文件，只把摘要带回上下文。
* **预算与超时**：按任务设 token、工具调用、时长上限，超限降级或转人工。

### 4.9 计费与多租户

* 成本要能归集到**租户 → 部门 → 岗位 → 任务**，否则无法算 ROI。
* 模型调用、工具调用、人工接管、存储、运维分开计量。
* 配额、限流、降级策略要按租户配置，避免一个部门把全公司预算打穿。
* 计费口径要写进合同：坐席、调用、任务、结果分别对应什么。

***

## 5. 生命周期：入职 → 培训 → 上岗 → 绩效 → 异常 → 下线

| 阶段 | 目标 | 关键动作 | 退出标准 | 常见失败 |
| - | - | - | - | - |
| 入职 | 把岗位配置出来 | 岗位说明书、身份、权限、工具、知识、评测集 | 岗位契约评审通过 | 只配了 Prompt |
| 培训 | 让它懂企业口径 | 知识入库、技能蒸馏、金标准集、影子运行 | 离线评测达标 | 知识过期、口径冲突 |
| 上岗 | 小范围验证 | 灰度 5% → 20% → 50%、人审兜底、回滚预案 | 灰度期指标达标 | 一上来全量 |
| 绩效 | 证明持续有效 | 周度记分卡、抽样审计、漂移检测 | 连续周期达标 | 只看调用量 |
| 异常 | 出事能兜住 | 重试、降级、人工接管、incident 复盘 | 恢复 + 根因闭环 | 没有升级路径 |
| 下线 | 安全退出 | 知识沉淀、权限回收、数据保留/删除、交接 | 审计确认 | 权限和数据留在原地 |

### 5.1 培训：先培训、再考核、后上岗

科大讯飞 WinWork 公开提出的"先培训、再考核、后上岗"，本质是把 Agent 当员工而不是当接口：

1. **培训**：把 SOP、制度、历史案例、专家经验灌进去，形成可检索、可引用的岗位知识。
2. **考核**：用固定任务集 + 金标准答案 + 边界案例评测，达不到就不上岗。
3. **上岗**：先影子模式（Agent 做、人不采用），再人机双跑，最后灰度放量。

### 5.2 灰度与回滚

* **影子模式**：Agent 输出不进入业务，只和人对比，积累差异样本。
* **人审模式**：Agent 输出必须人工确认，统计修改率。
* **灰度放量**：按订单类型、地区、金额、客户分层逐步放开。
* **回滚开关**：按岗位、按任务节点、按工具三个粒度都能关。
* **熔断**：错误率、越权率、投诉率超过阈值自动降级到人工。

### 5.3 异常处理

异常不是"报错"，要分类型：

| 异常类型 | 例子 | 处理 |
| - | - | - |
| 输入异常 | 缺材料、格式错、重复提交 | 退回补全，给出清单 |
| 工具异常 | 接口超时、权限不足、系统变更 | 重试、降级、切换通道 |
| 判断异常 | 低置信度、知识冲突、超出范围 | 转人工复核 |
| 合规异常 | 越权、敏感数据、对外发送 | 立即阻断 + 审计 + 通知 |
| 业务异常 | 金额不符、逻辑矛盾 | 挂起、补偿、升级 |

### 5.4 下线

下线不是关掉账号就完了。要完成：知识归档、经验蒸馏、权限回收、数据按合规保留或删除、在办任务交接、事故与改进记录入库。否则下一个"员工"还要从零再踩一遍坑。

***

## 6. 三个完整场景走查

### 6.1 场景一：银行信贷材料审核

**输入**：企业营业执照、财报、流水、征信、合同、抵押材料、行业资料；申请人信息、授信方案、内部制度。

**任务图**：

```text theme={null}
触发（客户经理提交）
  → 材料完整性检查
  → 主体与关联关系识别
  → 财务数据抽取与勾稽
  → 征信/流水/合同交叉验证
  → 风险点定位（异常交易、负债、诉讼、关联占款）
  → 生成审查意见（带证据与置信度）
  → 人工复核 / 补充材料
  → 审批流
  → 归档与质检
```

| 维度 | 设计 |
| - | - |
| 工具 | OCR、文档解析、企业知识库、征信接口、财务规则引擎、反欺诈模型、审批系统 |
| 产物 | 材料清单、财务摘要、风险点列表、审查意见、证据引用、置信度 |
| 异常 | 材料缺失退回；财报勾稽不平挂起；知识冲突升级；高风险点必须人工 |
| 人工介入 | 授信结论、风险定性、例外审批、对外沟通 |
| 验收 | 风险点召回率、误报率、审查意见一次通过率、平均时长、审计完整率 |

**关键机制**：把任务拆成**抽取 → 勾稽 → 交叉验证 → 风险定位 → 意见生成**，每个节点都有证据和校验，避免让模型"读完整份报告直接给结论"。银行场景的难点在**可解释、可追责、可复核**，生成本身并不难。

### 6.2 场景二：研发设计流程（显示/硬件类）

参考 TCL 华星公开的"显示研发设计全流程硅基员工"思路：融合大模型、多智能体与专业工程工具，打通方案策划、设计、仿真、验证与品质管理。

**输入**：客户需求、历史项目、器件库、工艺规则、仿真工具、测试数据、品质标准。

**任务图**：

```text theme={null}
需求解析
  → 方案检索与可行性分析
  → 多方案生成
  → 参数寻优
  → 仿真验证（多工具并行）
  → 工程数据/测试结果交叉验证
  → 风险识别与设计改进
  → 人工评审
  → 设计冻结与量产导入
```

| 维度 | 设计 |
| - | - |
| 工具 | PLM、器件库、仿真软件、工艺知识库、测试系统、品质系统 |
| 产物 | 需求解析报告、方案对比、参数集、仿真报告、风险清单、设计变更建议 |
| 异常 | 仿真不收敛、参数越界、工具版本不一致、结果与历史冲突 |
| 人工介入 | 方案取舍、设计冻结、量产放行、跨专业冲突裁决 |
| 验收 | 一次做对率、仿真覆盖率、设计周期、试错轮次、量产不良率 |

**关键机制**：这类场景的价值不在"生成一个方案"，而在**把数十个专业工具的调用、参数寻优和交叉验证编排起来**，把原来串行的试错折叠成并行探索。公司口径的"响应速度提升 80%"应理解为该企业特定流程的结果，不是通用常数。

### 6.3 场景三：数据分析日报

**输入**：业务系统数据、指标口径、历史日报、异常事件、组织权限。

**任务图**：

```text theme={null}
定时触发
  → 按口径取数
  → 数据质量检查（缺失、重复、口径漂移）
  → 指标计算与同比/环比
  → 异常检测与归因
  → 生成图表与结论
  → 业务负责人复核
  → 发布 / 推送
  → 反馈与修正
```

| 维度 | 设计 |
| - | - |
| 工具 | 数仓、指标平台、BI、异常检测、文档/PPT 生成、消息推送 |
| 产物 | 日报文档、看板、异常清单、归因结论、行动建议 |
| 异常 | 数据延迟、口径变更、异常无法归因、权限不足 |
| 人工介入 | 口径变更确认、重大异常定性、对外发布 |
| 验收 | 数据准确率、按时交付率、异常召回率、人工修改率 |

**关键机制**：日报的难点在**口径统一 + 数据质量 + 异常归因**，"写"本身不难。如果口径不统一，Agent 写得越流畅，错得越有说服力。

***

## 7. 责任与治理

### 7.1 出事故谁负责

Agent 不是法律主体，责任一定落在**部署者、使用者、供应商**之间的合同与流程上。

| 角色 | 责任 |
| - | - |
| 部署企业 | 对业务结果、权限设置、审批流程、员工培训负责 |
| 岗位负责人 | 对岗位边界、KPI、异常升级、验收负责 |
| 操作员工 | 对自己确认/审批的动作负责 |
| 供应商 | 对产品能力、安全基线、漏洞修复、服务 SLA 负责 |
| 模型提供方 | 对模型能力与安全声明负责，但不替代部署者的业务责任 |

### 7.2 审计证据链

小事故靠日志，大事故靠证据链。至少要能回答：**谁授权、Agent 做了什么、依据是什么、谁审批、谁验收、有没有异常、钱花在哪。** 证据链要防篡改、可导出、保留期符合监管要求。

### 7.3 数据边界与合规

* 数据最小化：只给完成任务必需的字段。
* 目的限定：不能拿业务数据去训练通用模型，除非合同明确授权。
* 跨境与个人信息：按法规做评估、脱敏、隔离。
* 供应商数据使用：写清楚是否留存、是否训练、保留多久、如何删除。
* 模型风险：高风险场景要有模型评估、人工复核、变更管理。

### 7.4 自建还是采购

| 判断维度 | 更适合采购 | 更适合自建 |
| - | - | - |
| 业务差异化 | 通用办公、标准流程 | 核心业务、独特 SOP |
| 数据敏感度 | 低/可脱敏 | 高/不能出域 |
| 迭代速度 | 供应商迭代更快 | 内部流程变化快 |
| 集成复杂度 | 标准连接器可覆盖 | 深耦合存量系统 |
| 总成本 | 小团队、快速上线 | 大规模、长期成本更优 |
| 锁定风险 | 可接受 | 不可接受 |

多数企业的现实答案是**混合**：通用能力采购，核心知识与流程自建，权限和审计留在自己手里。

***

## 8. 深度面试追问：及格回答 vs 满分回答

### 追问 1：怎么判断一个岗位值不值得做成硅基员工？

**及格回答**：看这个岗位是不是重复性高、规则清晰、人多。重复性越高越适合。

**满分回答**：我会用六个维度打分：规则清晰度、数据可得性、结果可验证性、异常长尾、协作密度、合规敏感度。规则清晰但例外多，说明需要判断和升级路径；数据不可得，说明要先做系统集成；结果不可验证，就不能考核。总分低就先做 Copilot 或 Workflow，不要为了"硅基员工"这个概念硬上。最终还要看单位产出成本，而不是只看人力节省。

### 追问 2：硅基员工和 RPA、Workflow 的本质区别是什么？

**及格回答**：RPA 是固定脚本，硅基员工能理解自然语言、能规划、能处理异常。

**满分回答**：执行依据和责任边界都不同。RPA 对"动作执行"负责，界面一变就断；Workflow 对"路径走完"负责，长尾例外覆盖不了；硅基员工对"结果合格"负责，所以它必须有目标、SOP、工具、校验、异常升级和审计。反过来说，如果流程极其稳定、没有例外，用 RPA 更便宜，不需要上大模型。

### 追问 3：权限怎么设计，才能既好用又不越权？

**及格回答**：按最小权限，敏感操作加审批。

**满分回答**：四层：第一，按人授权，用户能看的 Agent 才能看，不共享超级账号；第二，按任务节点授予工具、字段、行级权限，最小化；第三，高风险操作用临时授权和二次鉴权，资源层每次校验，不只信模型；第四，全链路审计和可撤销。Agent 自己不能持有数据库账号，模型只能通过受控资源层读写。这样即使 Prompt 被注入，破坏面也被限制在授权范围内。

### 追问 4：长任务跑到一半失败，怎么办？

**及格回答**：重试，不行就报错让人处理。

**满分回答**：先区分失败类型：上下文、工具、判断、业务、合规。工程上做渐进式披露、进展检测、上下文压缩、工具结果落盘、预算和超时；业务上做检查点、幂等、补偿和断点恢复。低置信度转人工复核，越权立即阻断，工具故障降级或切换通道。长任务追求的是"随时可恢复、可解释、可接管"，"一次跑完"并非目标。

### 追问 5：KPI 怎么设计，才能防止 Agent 刷指标？

**及格回答**：考核准确率和处理量，再加人工抽检。

**满分回答**：结果、过程、风险三层成对设计。结果看合格交付率和一次通过率；过程看时效和人工接管率；风险看越权、投诉、合规驳回。只考处理量会批量产出垃圾，只考准确率会只接简单单子。还要做任务分层和抽样审计，防止 Agent 学会"挑活"。KPI 的目标是让 Agent 的行为和业务价值一致，不是让数字好看。

### 追问 6：硅基员工出了业务事故，责任怎么算？

**及格回答**：Agent 没有责任，谁用谁负责。

**满分回答**：责任在部署企业、岗位负责人、操作员工、供应商之间的合同和流程里。技术上必须能还原：谁授权、Agent 做了什么、依据哪条知识、调用了什么工具、谁审批、谁验收。高风险动作必须人工确认，不能把责任模糊成"模型自己决定的"。供应商承担产品能力和安全基线责任，但不替代企业的业务责任。

### 追问 7：自建还是采购？

**及格回答**：有钱自建，没钱采购。

**满分回答**：看四个变量：业务差异化、数据敏感度、集成复杂度、长期成本。通用办公和标准流程适合采购；核心业务、独特 SOP、高敏感数据适合自建；多数企业是混合。采购时要看数据是否用于训练、权限能否按人授权、审计能否导出、退出时知识能否带走。最贵的是被锁定后无法迁移，license 费用反而是小头。

### 追问 8：怎么做灰度上线？

**及格回答**：先小范围试用，没问题再推广。

**满分回答**：分三段：影子模式，Agent 输出不进入业务，只和人对比；人审模式，输出必须人工确认，统计修改率；灰度放量，按订单类型、地区、金额、客户分层逐步放开。每一段都有退出标准、熔断阈值和回滚开关，回滚粒度到岗位、任务节点和工具。灰度不是"试试看"，是带着验收标准的受控实验。

### 追问 9：为什么很多数字员工项目停在 Demo？

**及格回答**：模型不够好，或者数据不够多。

**满分回答**：多数出在底座和流程上：没有统一口径、没有系统连接、没有权限约束、没有评测集、没有异常升级、没有人为 Agent 改造流程。Demo 只需要模型和工具，生产需要身份、权限、知识、记忆、审批、审计、计费。还有一个组织问题：岗位负责人没有对结果负责，项目就变成 IT 的自嗨。

### 追问 10：怎么算一个硅基员工的 ROI？

**及格回答**：省了多少人、多少时间。

**满分回答**：用单位合格产出成本，而不是单看 token 价格。公式是（模型 + 工具 + 人工接管 + 集成 + 运维 + 合规）/ 合格交付量，再和原岗位的单位产出成本比。收益侧看合格交付量、时效、返工率、风险损失下降。还要算上线成本和迁移成本。很多项目 token 很便宜，但人工复核和异常处理把成本吃回去了。

***

## 9. 来源与延伸阅读

* 腾讯云 WorkBuddy 产品文档：[专家](https://cloud.tencent.com/document/product/1831/134393)（2026-10-15）、[专家管理](https://cloud.tencent.com/document/product/1831/134421)（2026-11-13）。
* 腾讯云开发者社区：[腾讯企业智能体 WorkBuddy Enterprise 产品功能](https://cloud.tencent.com.cn/developer/techpedia/2677/21381)（2026-08-04）。
* 上海证券报：[腾讯正式发布 WorkBuddy 企业版](http://finance.sina.cn/2026-06-05/detail-iniaiyys8458606.d.html)（2026-06-05）。
* 贵州省大数据局转述：[让 AI "会干活"，看贵州科学城如何玩转"一人公司"](https://dsj.guizhou.gov.cn/ztzl/rdzt/rgznyycjpyhkf/xctg/202609/t20260915_90873945.html)（2026-09-15，合作方口径）。
* 证券日报/中国经济网：[TCL 华星硅基员工昨日正式上岗](http://www.ce.cn/cysc/newmain/yc/jsxw/202611/t20261114_3294176.shtml)（2026-11-14）。
* 新华网：[酷开发布企业 AI 操作系统](http://www.xinhuanet.com/tech/20260629/58a950e84ab0403e8c529d90da4cb4ff/c.html)（2026-06-29）；科技日报：[企业 AI 操作系统依托"四大智能体"](http://www.stdaily.com/web/gdxw/2026-06/28/content_538754.html)（2026-06-28）。
* 北京经开区/亦城时报：[硅基打工人来了](https://kfqgw.beijing.gov.cn/cxyzkfq/yzal/202611/t20261111_4941868.html)（2026-11-11，永洪科技）。
* 苏州新闻网：[懂业务会风控，这个"硅基员工"成银行"最强辅助"](http://sip.subaonet.com/2026/list/ffyq/sip_yqyw/0831/J1VwPm8r.html)（2026-08-31）。
* 中国经济新闻网：[数字员工"持证上岗"，企业 AI 迈向组织提效](https://www.cet.com.cn/itpd/itxw/10615929.shtml)（2026-10-16，科大讯飞 WinWork）。
* 阿里云帮助中心：[云联络中心数字员工计费](https://help.aliyun.com/zh/ccs/cccai/product-overview/product-billing-digital-employee)（2026-10-28，公开价格示例）。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.