9月23日，在云栖大会"Qoder 赋能超级个体"分论坛现场，阿里云智能集团专有云 AI platform 团队智算解决方案总监高萱带来主题演讲《团队里的硅基同事程知远——基于 QoderWake 的数字员工实践》。
高萱分享了团队基于 QoderWake 建设的数字员工"程知远"的完整实践。他从"为什么要招一名数字员工"讲起，指出模型能力的量变引起质变、以及推进 AI native 边界这两个向度的驱动。
程知远具备部署升级、研发测试、运维支持、知识管理等多方面能力，通过接入层（钉钉）、推理层（QoderWake）、工作层三层技术架构，与艾维维、Nook、Trekky 等多个 Waker 组成协作团队，落地了一句话触发自动构建部署、日志异常到根因定位、环境问题修复、缺陷监控与自动修复等实战场景。
8 月中旬到 9 月中旬这一个月，程知远服务了 153 位对话者、239 个群聊，处理 3000 多个任务成功率 98.9%，产生 685 次代码提交覆盖 51 个代码库，参与 247 次缺陷处理其中 182 个自闭环解决。他最后提出：碳硅协同的时代已经到来，各位的下一个同事可能就是硅基的。
以下是演讲全文：
以下为演讲实录整理，以第一人称呈现，仅删减口语化表述，尽量保留原貌。
大家好，我是来自阿里云专有云 AI Platform 团队的高萱。今天我给大家带来的分享主题，是团队里一个硅基同事的建设。他是基于 QoderWake 来建设的，我们给它起了一个非常拟人化的名字，叫程知远。
先来看两个实际效果。左边这块屏，我通过阿里钉和程知远对话，给它下发了一个修复环境问题的任务：把文档和当前的报错情况发给它，让它按照标准流程解决。屏幕上是 QoderWake 的后台，可以看到它已经开始推理。
右边这块，是一项偏事务性的工作：让它帮团队预定一间会议室。同样是通过阿里钉下发任务，交给 QoderWake 后台处理。
从整体交互来看，QoderWake 的推理过程会同步到钉钉里，我们团队中的成员在每天都在用的熟悉界面中，就能和它无摩擦地交互。视频播放完毕——30 号的会议室已经预定好，另一边它也回复说，环境问题已经解决。
为什么要招一名数字员工
在正式介绍之前，有一个 why 的问题需要先回答：为什么要招一名数字员工？这背后有两个向度的思考。
一方面，AI Agent 和大模型的能力持续增强，已经由量变引起质变。无论是推理能力、长任务执行能力，还是对 SOP 的遵循能力，现在的模型都已达到和人类同级、甚至超过人类的水平。所以第一点，是希望通过建设数字员工来提升组织效能——这是来自模型能力侧的推动的向度：建设数字员工的条件已经齐备，时机已经成熟。
另外一个方向是，我们希望能进一步推进 AI native 的边界，达到一个更好的、在组织内的效果。过去有很多的机器人：问答机器人、工单答疑机器人、查企业规范的机器人等等。数字员工不满足于此，我们希望能够建设一个具有真人感的硅基同事。这样一来，大家就能把日常工作中那种重复性高、标准化程度高、但 ROI 相对较低的工作交给它完成，从而节省精力。这是我们想达到的最终目标。
程知远的能力与身份
程知远正是在这样的思考下应运而生。经过建设小组的培养，它已经具备部署升级、研发测试、运维支持、知识管理等日常研发各方面的能力。
值得一提的是，最开始并没有想到它会具备这么全面的能力，成为一个多面手。起初只是把它定位在研发场景，后来产品经历、项目管理人员，乃至前线的架构工程师，都开始使用程知远。这得益于最初做架构设计和整体权限设计时对原子化能力的强调，保持了开放性。架构和权限设计上的优势，使程知远职责的不断开拓成为可能。
这三张小图展示了它的工作身份：第一张是代码平台，第二张是 CICD 变更平台，第三张是钉钉文档。可以看到，程知远都在以自己的身份提交代码、创建变更、编写文档。
这里想强调一点：身份和权限决定能力边界。这也暗合了"程知远"这个名字——"程"代表工程、流程、编程；"知远"，是希望它拥有丰富的知识储备，并用这些技能帮助团队行稳致远。
正如刚才所见，用户只需在钉钉里像和真实同事聊天一样给它发消息，程知远就能理解意图，调用各类知识和学习文档完成任务。
三层技术架构
简单介绍一下技术实现，方便大家看到 QoderWake 是如何集成到整个流程中的。技术架构比较清晰，分为三层：接入层、推理层和工作层，也就是它的工作面。
接入层就是刚才看到的钉钉，在这一层也会先对钉钉会话做一定的预处理，比如保留对话者的信息、对语音消息先转文字、保留多媒体消息的媒体 id 等。
在推理这一层， @Waker 能力相当于多 Agent 之上一层的主控 Agent。这个主控 Agent 同样基于大模型、懂得意图推理，能判断一段对话究竟想做什么：是开启新对话、询问当前对话进展，还是交派新任务；理解好意图后，再把消息分发给背后不同的岗位的 Agent。这也是过程中我们作为使用者和 QoderWake 团队一起迭代取得的进步。
第三层是数字员工的工作面，即前面提到的项目协作、代码研发等工作，也是我们团队主要发力的方向。相当于去教它：不同场景该怎么做、该去哪个页面、操作什么。把这个过程沉淀出一系列 Skill，也是它构建起充分原子能力的过程。
一支丰富的 Waker 团队
除了程知远，还必须介绍一下背后一支庞大的 Waker 团队，这也是刚才 QoderWake 介绍中多 Waker 的一个具体落地。
团队创建了多个 Waker，其中使用特别频繁的有四五个。比如负责 AI Studio 产品研发的研发工程师，就是今天主要介绍的程知远；还有专门负责运维场景的艾维维、前端团队建设的 Nook，以及另一个团队建设的 Trekky。这很好地呼应了前面分享的理念：团队中的各个角色、兄弟团队、横向团队一起参与建设，把一个 Waker 发展成了一支丰富的 Waker 团队。
这和人类组织非常相像：适当分工能提升整体效率，Waker 也是如此。Waker 的记忆和 Skill 本质上都依托上下文完成。如果把前端、后端、前线运维等庞杂的知识都灌给一个 Waker，上下文压力会非常大，可能导致 Skill 选取不准、回答不够精确。因此，建设多个 Waker 有着天然的动因。
这些 Waker 并不是单打独斗。最开始，通过一个 waker collaboration 的 Skill 告诉它们：需要协作的时候，就去协作。比如艾维维是面向运维场景的答疑工程师。Skill 里告诉艾维维：群里遇到比较复杂、自己解决不了的问题，就转交给程知远，因为程知远的知识库非常全，而且具备代码权限——艾维维没有代码权限，这在安全上也是很好的隔离。艾维维会通过 waker collaboration 把问题转交给程知远，两者自行沟通，聊完后再由艾维维把结论带回群里回复。
再比如 Nook 和程知远的前后端联动：程知远接收到前端任务时，会把任务流转给 Nook；Nook 完成后，再整体给出结论，向上汇报或告知人类，等待人类进一步指示。这也体现了建设多个 Waker 的优势。
四个实战案例
接下来看几个非常有体感的实战案例，都是团队里真实发生的。
先说一个有意思的点：程知远最初瞄准的是研发场景，而研发涉及非常多的流程——从技术评估，到协作各方的需求拆分，再到编程实现、本地自测联调、发布部署、修复缺陷，最后发布并进入长期运维，是一长串的工作。目前除了联调阶段由于涉及图形界面完成得还不够好，其他环节程知远都已完成得相当出色。另外在团队中的一些开发共识信息的速查，以及内部验证环境偶然遇到的问题，程知远也都能迅速提供可靠的支持。研发团队里几乎每个人每天都在频繁使用它。
第一个场景，一句话触发自动构建部署。 过去做构建部署，要对着文档操作，新同事或不常做部署的同事往往一头雾水，只能对着文档一步步摸索。但这类流程清晰的事情，显然应该交给 Agent。于是部署能力被沉淀成Skill 交给了它，操作方式随之改变：在钉钉上跟它说一句"把某代码库的某分支部署到某场景的某环境"，它会先确认部署要素——什么产品、什么版本、什么环境，回复确认后便开始部署。结果是，部署操作 100% 交给了AI。过去人工部署，熟练的要花三十分钟，不熟练的要一个小时，这些时间现在都省了下来，可以去做别的事情。
第二个场景，从日志异常到根因定位。 环境中难免会遇到各种问题，过去往往要找对应模块的同事帮忙排查、解决。现在程知远知识储备丰富，直接交给它就行：截个图或贴一段日志，告诉它"分析一下环境中出现以上错误的原因"，它就会基于自己的知识进行排查。它不仅能解释异常是怎么回事，还能把根因定位出来——这得益于它拥有环境权限，能把静态日志和环境中的真实情况、真实水位两相对照，定位过程因此更可信、更准确。
第三个场景，环境问题修复。 这是实际体验中非常爽的一个场景。我曾真实遇到过：有一天环境的前端登不上去了。过去肯定要找对应模块的负责人，请他帮忙看一下、解决一下。现在直接扔给程知远："这个环境有问题，帮我看一下"，十分钟之内就解决了。过去找人要耗费不少精力，消息未必能被及时看到，要一环一环路由到负责的同事，对方再花时间定位、解决；现在直接在钉钉里讲一声，很快就能搞定。我把它总结为"横向问题不求人"，体验非常高效。
第四个场景，缺陷监控与自动修复。 得益于 AI Coding 的长足发展，这是 AI 非常熟悉、也非常擅长的领域。我们给它设置了定时任务，定时检查某个空间下的缺陷情况。它会把缺陷连同分析和初步结论通过钉钉发过来；确认之后，它就按照建议的方向进行修复。
一个月成绩单
最后来看它的一个成绩单。我选取了 8 月中旬到 9 月中旬这一个月时间窗口的运行情况。
在这个时间窗口，它有 153 位对话者，服务了 239 个群聊；这些对话者给它交给了 3000 多个任务，成功率是 98.9%，比较高。在代码活动方面，比如代码的提交、代码的合并申请等等，一共产生了 685 次提交，覆盖了 51 个代码库。在刚刚提到的缺陷上，它参与了 247 次缺陷处理，其中有 182 个都是它自闭环解决的。
所以能看到，在整体的研发提效、团队整体提效上，它是实打实地做出了一些成绩的。
最后我想说：一个碳硅协同的时代已经到来，我们恰好在这个浪潮上。各位的下一个同事，可能就是硅基的。
谢谢大家。
