那天上午，数字人替我接住了一个产品需求。
对方问某个功能能不能做。按过去的工作方式，我要先翻群聊、会议纪要、产品文档，再去看相关代码和权限边界，最后给出判断。可这一次，数字人先把这件事拆开了：当前为什么能做，哪里暂时不能做，背后依赖哪个系统，为什么优先级应该调整。
这件事发出来以后，大家最关心的问题变成了一个：到底怎么实现？
如果只说“自研平台 + 独立云端沙箱 + 钉钉能力网关 + Claude Code Agent + 数字人输出”，还是太虚。别人听完知道方向，但不知道从哪里下手。真正能抄走的方案，必须讲清楚每条消息怎么进来、上下文怎么拼、Agent 怎么常驻、权限怎么卡住、输出怎么分段、审批怎么确认、日志怎么回放。
专属身份数字人的实现，本质上不是做一个聊天机器人，而是做一个绑定员工身份的事件驱动工作系统。
下面这篇我就按可以复刻第一版的方式讲。不是堆概念，也不是只讲产品愿景，而是把端到端链路拆到模块、数据、进程、规则和验收。
一、先把目标定死：它不是任务助手，而是身份代理
小龙虾、WorkBuddy 更像“我把任务交给 AI”，身份级数字人更像“组织里的事件先找到 AI”。
这两类产品的工作位置完全不同。任务型办公 Agent 的入口是人：你打开产品，输入目标，上传材料，告诉它帮你写、查、改、跑。它解决的是“我现在有一件事，能不能让 AI 快点做”。
身份级数字人的入口是事件：有人在钉钉找你，项目群里出现卡点，审批单到了你的名下，某个需求被反复追问，会议纪要里产生了待办。它不是等你派任务，而是在授权范围内监听工作现场，把事件转成一个待处理任务。
所以它的最小闭环不是“输入一句话，输出一段回复”，而是：事件进入、身份识别、上下文补齐、规则判断、Agent 推理、工具动作、输出控制、人工确认、审计归档。
这也是为什么它必须绑定真实工作身份。不是为了弱化 AI 标识，而是因为企业协作本来就围绕身份、权限和责任运转。数字人可以代理本人处理部分工作，但必须做到可授权、可标识、可暂停、可审计。
二、总架构：平台调度，一人一沙箱，消息进队列
第一版不要做成一个大机器人，要做成“平台控制面 + 用户独立运行面”。
平台控制面只负责五件事：员工身份台账、授权入口、沙箱调度、策略配置、审计查询。真正读消息、跑 Agent、保存会话、执行工具的逻辑，都放在用户自己的隔离运行空间里。
最小数据表可以这样设计：identity_profile 存姓名、岗位、职责、沟通风格和禁答边界；sandbox_instance 存用户对应的运行空间、状态、资源配额和启动时间；credential_binding 存授权状态、权限范围、续期状态和撤销状态；conversation_event 存进入系统的每条消息事件；context_chunk 存可检索的上下文切片；agent_job 存每次 Agent 处理任务；tool_call 存每次工具调用；approval_ticket 存需要人工确认的动作；audit_log 存最终可回放链路。
沙箱内部至少有六个目录或服务：凭证托管区、消息监听进程、上下文缓存、长期记忆索引、Agent 运行目录、工具网关。凭证托管区只给沙箱内部进程读；上下文缓存放当前群聊和单聊窗口；长期记忆索引用来检索历史会议、文档和决策；工具网关负责把“读消息、发消息、查日程、查审批、查代码、写文档”等能力包装成受控工具。
消息进入后不要直接喂模型。先进入事件队列，生成 job_id，再由 Agent worker 按会话维度串行处理。这样做有两个好处：第一，同一个群里连续消息不会互相打架；第二，后面才能做中断、重算和审计。
授权不是登录一下这么简单，它决定数字人到底能看什么、能做什么、出了问题能不能停。
这里有三个原则。第一，权限范围要最小化。第一版只要工作消息读取、指定会话发送、可见历史上下文读取、通讯录基本信息、日程和审批查询即可，不要一上来申请删除文件、改组织架构、批量改权限这类高危能力。
第三，授权要和策略绑定。即使某个身份本身拥有审批、代码、文档权限，数字人也不能默认自动执行所有动作。授权解决“能不能调用系统”，策略解决“此刻能不能让 AI 自动做”。
照着做时，至少要有三个开关：数字人总开关、自动回复开关、高风险动作人工确认开关。总开关停运行，自动回复开关停输出，高风险开关决定审批、权限、代码、合同、客户承诺类动作必须走人工确认。
四、消息监听：先把钉钉事件变成标准事件
工作消息接入层不要直接服务模型，它应该先把所有消息变成统一事件。
钉钉侧可以参考 Stream SDK 或企业内部的工作消息连接层。长连接收到消息以后，监听进程先做标准化，统一成一个 event envelope：event_id、tenant_id、user_id、conversation_id、conversation_type、sender_id、message_id、message_type、timestamp、content、at_list、attachments、source_app、raw_payload。
这一步很关键。后面的 Agent 不应该关心钉钉、飞书还是企业自研 IM，它只消费标准事件。你未来要接飞书、企业微信、邮箱、工单系统，只要把输入统一成同一套 event envelope 即可。
标准化以后做四件事：第一，去重，用 message_id 和 event_id 防止重复消费；第二，落库，把原始消息和标准事件都保存，方便回放；第三，触发判断，看这条消息是不是白名单会话、是不是 @ 本人、是不是包含待办或请求；第四，入队，生成 agent_job。
第一版触发规则可以很简单：指定单聊必进队列，白名单群里 @ 本人进队列，白名单群里出现明确任务词进队列，系统通知类审批和权限请求进队列。不要一开始监听所有消息都推给模型，否则成本、噪音和风险都会失控。
五、上下文拼接：不是向量库一把梭，而是四层上下文
数字人像不像你，核心不在口吻模仿，而在它拿到的上下文是否完整、干净、有来源。
Agent 处理一个 agent_job 前，先由 context_builder 组装四层上下文。
第一层是当前消息。包括谁发的、在哪个群、是否 @ 本人、原文是什么、附件是什么、消息前后几条是什么。第二层是当前会话历史。拉取这个群或单聊最近一段时间的可见历史，按时间线压缩成“发生了什么、争议点是什么、未完成事项是什么”。
第三层是个人长期记忆。这里存的是这个员工过去在会议、文档和聊天里形成的判断，而不是所有原文无脑塞进去。比如“这个项目优先级长期低于 A 项目”“某类权限开通需要先看业务必要性”“该产品线过去反复强调不要增加人工审核节点”。
第四层是企业知识和工具结果。包括制度、PRD、代码检索结果、审批单、日程、任务、知识库和业务系统记录。这里要保留来源标签，让 Agent 回答时知道每个判断来自哪里。
上下文拼接时要做三件事：先过滤敏感和无关内容，再按任务类型选上下文，最后把来源和置信度一起交给模型。第一版可以按“当前消息 10%、会话历史 30%、长期记忆 30%、工具结果 30%”来控制 token 预算，后面再调。
六、Agent 主循环：Claude Code 常驻沙箱怎么跑
不要每来一条消息就临时起模型，身份数字人需要一个常驻 Agent worker。
沙箱启动后，常驻三个进程：message_listener、agent_worker、output_controller。message_listener 负责接消息和入队；agent_worker 负责消费 agent_job；output_controller 负责把候选输出分段发送、中断或等待人工确认。
agent_worker 的主循环可以按这个顺序写：取 job，锁定 conversation_id，读取 identity_profile，加载系统提示词，调用 context_builder，生成 task_brief，做一次策略预判，启动 Claude Code Agent，允许它调用沙箱内工具，拿到候选回复和候选动作，再交给 policy_engine 做二次校验。
系统提示词不要只写“模仿某人说话”。它至少要包含七块：身份职责、业务边界、沟通风格、禁止事项、权限动作等级、需要人工确认的条件、输出格式。尤其要写清：不知道就查工具，查不到就说明不确定；涉及审批、权限、代码、合同和客户承诺时，不得绕过确认。
Claude Code 的价值在于它不只是生成文本，还能在沙箱里使用工具：查文件、读项目资料、检索代码、执行受控脚本、调用内部 CLI。这里的关键不是让它随便跑命令，而是把所有工具都包一层 tool_gateway。Agent 只能调用白名单工具，工具调用前检查权限，调用后记录结果和证据。
最小主循环可以记成一句话：事件进来，补上下文，Agent 生成候选判断，策略引擎决定能不能做，输出控制器再把结果发回原会话。
七、权限动作：把“能说”变成“能做”，靠工具网关和策略引擎
模型不能直接拥有权限，模型只能提出动作，工具网关决定能不能执行。
所有动作分五级。第一级是 read，只读信息，比如查消息、查文档、查审批状态。第二级是 draft，生成草稿，比如回复草稿、催办草稿、审批意见草稿。第三级是 send，发送工作消息或评论。第四级是 write，改文档、回写任务、修改状态。第五级是 approve，审批、开权限、合并代码、对外承诺这类会改变责任链的动作。
第一版建议 read 和 draft 自动放开；send 只在白名单会话、低风险话题和明确置信度下自动；write 需要本人确认或规则白名单；approve 默认必须人工确认。
实现上，Agent 输出不能直接是“我已经审批了”。它应该输出 action_plan：要调用什么工具、输入是什么、依据是什么、风险级别是什么、是否需要确认。policy_engine 读取 action_plan 后，根据身份、会话、动作等级、关键词、上下文来源和企业规则判断下一步。
如果可以自动执行，tool_gateway 调用对应工具并记录 tool_call。如果需要确认，生成 approval_ticket，推给本人确认。如果禁止执行，Agent 只能解释原因并给出替代建议。
这层做对了，数字人才从“会说话”变成“能干活”。这层做错了，它就会变成一个拿着真实权限乱跑的模型。
八、输出控制：先生成完整判断，再分段发送，随时中断
流式输出不是把模型 token 直接吐到群里，而是把完整判断拆成可控消息。
正确做法是：Agent 先生成完整 response_plan，包括结论、依据、建议动作、需要确认的点和发送对象。output_controller 再根据会话类型和用户风格切成 2 到 5 段短消息。
每段发送前都做一次状态检查：这个会话有没有新消息进来，原问题是否已经被别人回答，数字人总开关是否关闭，自动回复开关是否关闭，当前输出是否需要人工确认。如果任何条件变化，立刻 cancel 当前输出，把 job 标记为 interrupted，再用新上下文重新生成。
分段节奏要遵守平台规则和企业合规要求，不要做绕过风控的伪装。它的目的只有两个：让工作沟通更自然，让系统可以在中途停下来。数字人越像人，越要在后台有更强的刹车。
如果接入语音和虚拟形象，文本仍然是主链路。TTS 和口型驱动只是输出层，不要让多模态反过来影响业务判断。先保证文本闭环可控，再做音色、形象和视频呈现。
九、审计回放：每一次读、想、做都要能还原
企业敢不敢用身份数字人，最后看的是能不能回放责任链。
audit_log 至少记录这些字段：job_id、event_id、user_id、conversation_id、trigger_reason、context_sources、prompt_version、policy_version、model_version、tool_calls、action_plan、risk_level、human_confirmation、final_output、send_status、created_at。
这里面最容易漏的是 prompt_version 和 policy_version。没有版本号，出了问题你不知道当时数字人遵守的是哪版规则。另一个容易漏的是 context_sources。没有来源，数字人说得再像真相，也无法证明它为什么这么判断。
回放页要能按一个 job 展开：原始消息是什么，系统拉了哪些上下文，Agent 给出的候选判断是什么，策略引擎为什么允许或拦截，调用了哪些工具，最终发出了什么。如果有人投诉“这句话不是我说的”，系统要能在一分钟内回答：这是 AI 自动回复、本人确认回复，还是草稿被人工修改后发送。
十、照着搭第一版：四周做出可演示 MVP
第一版不要追求全公司通用，先做一个人的白名单场景闭环。
第一周做平台和沙箱。建 identity_profile、sandbox_instance、credential_binding、audit_log 四张核心表；完成用户开启、授权、创建沙箱、停止沙箱、撤销授权；沙箱里跑 message_listener、agent_worker、output_controller 三个进程。
第二周做消息接入和上下文。接钉钉 Stream 或企业消息网关，把消息标准化成 event envelope；完成去重、落库、白名单触发和 agent_job 队列；实现 context_builder，先支持当前消息、会话历史、用户配置和文档检索四类上下文。
第三周做 Claude Code Agent 和工具网关。把身份提示词、上下文、任务摘要和工具列表注入 Agent；工具先支持查消息、查文档、查日程、查审批状态、生成回复草稿、发送白名单会话消息；每次工具调用都写 tool_call 和 audit_log。
第四周做策略和输出。实现权限动作分级、人工确认票据、分段输出、中断重算、审计回放页。验收时只看四类场景：有人问需求背景，它能基于历史上下文回答；项目卡点出现，它能生成催办草稿；权限或审批请求进来，它能判断是否需要人工确认；新消息打断时，它能停止旧输出并重新组织回复。
这就是可以抄走的第一版。它不追求一开始替代所有员工，也不追求所有动作自动化。它先证明一件事：在一个明确授权的身份、几个白名单会话、一组低风险动作里，AI 能不能带着上下文和权限，把一段真实工作闭环接住。
九、公开参考
1. open-dingtalk：DingTalk Stream SDK Python，用于钉钉 Stream Mode API 的公开 SDK。 查看 GitHub
2. jizhilong：钉钉 AI 助理直通模式与流式回复演示，基于 dingtalk-stream-python SDK。 查看 GitHub
3. Anthropic：Claude Agent SDK Python 与 Claude Code SDK demos，提供 Agent 能力开发参考。 SDK / Demos
4. dzhng：claude-agent-server，把 Claude Agent 放在沙箱里并通过 websocket 控制。 查看 GitHub
5. schmitthub：clawker，用隔离 Docker 容器运行 Claude Code，并做外联边界控制。 查看 GitHub
6. OWASP 与 NIST：Agentic Applications 风险框架与 AI Risk Management Framework，可作为企业安全治理参考。 OWASP / NIST