从业务场景到组织体系，“龙虾” 如何走进企业

阿里云最近几站“虾友会”释放出的一个核心信号是：“龙虾”已经不再只是技术圈里好玩的 Agent 工具，而是在被推向企业可接纳、可治理、可持续运行的数字员工体系。对 App 开发者、产品经理和增长团队来说，【龙虾上岗】真正值得关注的，不只是企业开始养虾，而是外部 Agent 发起的任务流量正在变成新的业务入口，原有安装归因与渠道解释框架很可能会越来越不够用。

新闻与环境拆解

“龙虾”讨论的重心，已经从个人效率转向企业上岗

过去几个月，“龙虾”最先被市场看到的，是它在执行层面的强能力：抓网页、调工具、写报告、跑任务，甚至接管一部分重复劳动。很多围绕 OpenClaw 的讨论，一开始都停留在个人体验上：它能不能代替传统聊天机器人更进一步，它是不是终于能把“你说一句，它真去干活”这件事跑通。

但企业面对的根本不是同一道题。个人用户问的是“它能替我做什么”，企业问的却是“它怎么进入业务系统、怎么进入组织、怎么被管理”。这也是阿里云“虾友会”反复强调的切换点：当“龙虾”开始接近数字员工，企业首先看到的已经不是演示视频里的能力，而是工作入口、组织边界和运行环境。

这件事很重要，因为它意味着“龙虾”不再只是一个模型能力故事，而开始变成一个企业软件架构问题。谁来接入、接到哪、通过什么权限边界接、出了错谁负责、日志怎么查、审计怎么做、内部员工怎么调用，这些都不是附加问题，而是“龙虾”能不能进入企业现场的前置条件。

企业第一道门槛不是模型，而是业务场景能不能接住它

从“虾友会”披露的案例看，企业场景对 Agent 的要求，明显已经超过了“会聊天、会生成”的个人工具边界。无论是电商企业统一桌面、网页和移动端的运营自动化，还是新能源车企把招聘、报销、请假等流程进一步自动化，还是金融场景里把数据采集、分析、可视化压缩成一条连续链路，这些任务有个共同点：它们都不是单点任务，而是跨环境、跨工具、跨系统的连续流程。

这意味着企业真正面对的，已经不是“怎么把 Agent 用起来”，而是“怎么把它接进真实业务链路”。一个能跑任务的 Agent，如果只能停留在对话框里，对企业价值其实很有限。企业要的是它能进入桌面、进入浏览器、进入 IM、进入表格、进入研发流程、进入内部系统，并在多个环境之间衔接动作。

也正因为如此，像无影 JVS Claw、QoderWork 这类桌面侧和工作面产品，承担的角色就不只是“提供一个入口”，而是让企业员工能在具体场景里调用 Skill、连接 MCP Tool，把“龙虾”从一个独立 AI 对话框推进成真实工作流里的操作单元。简单说，企业落地阶段最先解决的，不是“模型够不够聪明”，而是“工作现场能不能接得住它”。

入口成立之后，“龙虾”还要补三层：工牌、岗位能力、持续运营

“龙虾”进入企业，不会因为有了入口就自动获得数字员工资格。按照阿里云这套叙事，它至少还要补齐三层。

第一层是工牌，也就是身份和权限。
当 Agent 开始接入企业微信、钉钉、飞书、知识库、数据库和各种内网系统时，企业首先要解决的不是“它会不会干活”，而是“它到底是谁”。它属于哪个角色边界，继承谁的权限，哪些动作必须授权，哪些系统可以访问，哪些行为必须留痕审计。这一层本质上是把 Agent 从“工具”升级成“组织中的身份实体”。

阿里云在这部分给出的承接思路，是通过统一身份体系接入企业现有 SSO 和角色边界，再放入统一控制平面里，跟 IM、知识库、内网系统、审计日志、多租户治理等能力衔接起来。也就是说，工牌不只是登录认证，而是数字员工进入企业组织体系的第一张许可证。

第二层是岗位能力，而且这层能力分成“内部定义”和“外部连接”两部分。
从公开披露的“龙虾” workspace 结构看，其核心文件大致包括 SOUL、USER、AGENTS、TOOLS、MEMORY、memory、SKILL 七类。SOUL.md 更像行为风格和价值准则，USER.md 对应服务对象画像和偏好，AGENTS.md 规定任务逻辑和协作方式，TOOLS.md 规定工具边界，MEMORY.md 与 memory.md 则分别承接长期记忆与短期上下文，SKILL.md 负责把岗位经验和业务动作沉淀成可复用模板。

这套结构的真正价值，不在于“文件很多”，而在于它让数字员工不再靠一段临时 Prompt 上岗。它更像是一套岗位描述、员工手册、操作 SOP、权限边界和记忆体系的组合。对企业来说，这意味着龙虾不是一次性生成，而是可以被“定义、训练、固化、迭代”的。

再往前一步看，岗位能力如果只停留在内部定义，还只是“会做事的模板”；要真正进入业务，就必须把外部工具、服务、系统接口和数据源接进来。这正是 MCP 这类能力的重要性：Skill 更偏向沉淀企业内部经验和岗位 SOP，MCP 更偏向把外部能力标准化接入，让这些模板真正能调用系统、读写数据、触发服务。

企业最后真正卡住的，往往不是不会用，而是不会持续运营

当身份和岗位能力都补齐后，企业真正的难题会转向持续运营。对企业来说，数字员工不是一个“装完就完事”的玩具，而是一类需要持续维护、持续更新、持续监控的新型执行单元。

持续运营至少包含两层。第一层是工程运维能力：配置如何创建和编辑、任务与会话如何管理、运行状态如何查询、日志如何排错、版本如何更新、如何接 CI/CD、如何接知识系统、如何衔接运维体系。第二层则是日常业务入口：数字员工到底从哪里被员工调用，它是停留在命令行，还是进入文档、表格、浏览器、研发 IDE、IM 对话窗口和本地文件体系。

也正因为如此，阿里云在产品形态上明显不只想做一个“会跑的龙虾”，而是在尝试把同一套多智能体架构、上下文引擎、工具集、工程感知和模型调度能力，封装进不同岗位可直接使用的工作面。对办公侧来说，是文档、表格、文件、图表；对研发侧来说，是代码、测试、排障、发布；对企业控制侧来说，则是统一配置、权限、审计、知识库、MCP、Sandbox、API 和 IM Channel 收敛到同一套控制平面中。

归根结底，企业要的不是一个会干活的 Agent，而是一个可托管的运行单元

即便入口有了、工牌有了、岗位能力和持续运营也开始补齐，企业仍然不会轻易把一个能写代码、能调浏览器、能连系统权限的 Agent 直接丢进生产环境。问题最终还是会回到运行时：它到底跑在什么环境里，边界谁来划，错误谁来兜底，调用怎么审计，数据怎么隔离，成本怎么观察。

这也是为什么“虾友会”反复强调的不只是部署，而是 Agent Runtime。
从更轻量的 MVP 验证，到可托管、可精细权限控制的方案，再到具备弹性、隔离和审计能力的云原生沙箱，阿里云的判断很明确：个人尝鲜可以从“装起来”开始，但企业落地必须从“能托管、可隔离、可审计、可扩展”开始。

从这个角度看，企业最终要接受的，不是一个会说话、会干活的 AI 助手，而是一类需要被统一托管、隔离、监控和治理的新型执行单元。而“龙虾”能不能真正进入企业工作流，关键不在于它会不会做演示里的任务，而在于它能不能在企业接受的边界内持续工作。

从新闻到用户路径的归因问题

看到这里，普通读者可能会把这件事理解成“阿里云正在做企业 Agent 平台”；但如果你是 App 开发者、增长负责人或数据团队，真正要警惕的是另一件事：当【龙虾上岗】进入企业工作流后，流量的发起者、承接者和转化链条都开始发生变化。

以前很多 App 团队默认的路径是：用户看到内容、点击链接、到达落地页、完成安装、完成首启，再转化为注册或付费。可在【龙虾上岗】场景下，真正发起任务的未必是用户本人，路径中间也未必只有一个页面。一个招聘流程可能由内部 Agent 发起，一个报销流可能由 IM 里的数字员工触发，一个投研动作可能是由某个岗位 Skill 自动串起数据和表格后，把结果推送到某个 App 工作面里。

这时候，流量就不再只是“人物流量”，而开始出现“任务流量”。
所谓人物流量，是用户在 App 内直接完成浏览、点击、安装、注册和使用。
所谓任务流量，则是外部 Agent 工作流先发起任务，再把用户或结果导向某个 App、某个页面、某个深链、某个工作面。

问题在于，大多数现有归因体系对人物流量还算熟悉，但对任务流量几乎是失明的。后台报表可能只能看到“来自企业微信”“来自钉钉”“来自某个桌面端入口”，却根本看不到：

• 是哪个 Agent 在发起任务；
• 任务来自哪个场景；
• 中间经过了哪些系统；
• 用户是在什么业务上下文里被导向 App 的；
• 这个任务成功还是失败；
• 哪一步丢失了上下文。

对增长团队来说，这会直接制造一种错觉：流量明明来了，但为什么转化很差？
对产品团队来说，问题则变成：为什么高意图用户进入后像普通自然量一样流失？
对开发团队来说，更头疼的是：埋点里没有任务上下文，根本没法知道首启该恢复哪个场景。

换句话说，【龙虾上岗】真正影响的不是某个“AI 产品趋势判断”，而是 App 团队对入口定义权和归因解释权的控制能力。如果外部 Agent 已经在替用户发起任务，而你还在用传统安装口径看世界，那么很多高质量意图流量，最后都会在安装前后被系统“洗白”为一团普通来源。

工程实践：重构安装归因与全链路归因

渠道编号 ChannelCode：先把“谁带来的任务”分清楚

问题：
在【龙虾上岗】场景下，入口会快速碎片化。看起来都是“来自企业端流量”，但实际可能来自 JVS Claw 桌面工作面、QoderWork 办公入口、企微消息触发、钉钉 MCP 流转、技能模板分享，甚至是某个内部知识库页面跳转。所有这些入口，如果最后都被粗暴归到“企业来源”或“阿里云来源”，后面几乎没有优化空间。

做法：
更合适的方式，是先用 渠道编号 ChannelCode 把不同入口做标准化标识。例如，可以按入口和任务场景拆出：

• dragon_jvsclaw_hr
• dragon_qoderwork_ops
• dragon_dingtalk_mcp_finance
• dragon_wecom_agent_support
• dragon_skill_workspace_research

这样做的核心不是“多建几个渠道”，而是把原本混在一起的任务入口，统一收束到同一套可统计、可对比、可解释的标识体系里。

带来的好处：
一旦 ChannelCode 建立起来，增长团队看到的就不再只是“企业渠道带量不错”，而是“哪个数字员工入口带来了更高质量的激活，哪个岗位工作面带来了更高转化，哪个 Skill 模板只是带来了浏览却没有后续行为”。对 Agent 场景来说，这种入口分层几乎是归因系统能否工作起来的起点。

在方法上，也可以直接沿用 xinstall 在《亚马逊 AI 战略升级？多云多 Agent 时代 App 该怎么认清流量真身》里那套“多入口统一收束”的思路，把平台来源升级为任务来源，把渠道统计升级为工作流统计。

智能传参安装：把任务上下文从入口带进 App 内

问题：
即便入口分清了，任务上下文仍然可能在安装时丢失。企业用户不是泛泛地“装一个 App 试试”，而是带着非常具体的任务进入的，比如“完成一次招聘审批辅助”“打开一次投研数据工作面”“继续一条报销流程”“查看一份运营自动生成报告”。如果这些上下文在安装和首启后消失，前面所有任务流量价值都会被严重折损。

做法：
这类场景更需要通过 智能传参 把场景和意图参数带进安装链路。建议在链接侧至少考虑携带这些字段：

• agent_platform
• agent_id 或 workflow_id
• channelCode
• scene
• intent_type
• risk_level

例如，一个来自钉钉 MCP 的报销流任务，和一个来自 JVS Claw 的研发工作面任务，虽然最后都可能导向同一个 App，但其首启承接逻辑显然应该不同。前者可能要回到报销流程节点，后者可能应该直接恢复到代码协作或测试看板。

这类“链接携参 → 安装 → 首启 → 参数还原”的承接逻辑，可以直接参考 xinstall 在《智能体分发时代 App 安装传参逻辑的底层重构》里给出的思路，让 App 不只是记住“你从哪来”，而是记住“你为什么来”。

带来的好处：
一旦参数能被还原，产品就能在首启时恢复用户原本的任务上下文，免去重新搜索、重新选择入口、重新理解任务的过程。对企业任务流量来说，这一步极其关键，因为很多任务转化损耗，恰恰发生在“任务上下文断掉”的那一瞬间。

注：本文讨论的企业 Agent 任务流量承接、任务参数传递与首启场景还原，属于对未来分发趋势的前瞻性技术延展与思考，例如多 Agent 入口精细化归因、跨平台任务链路恢复、数字员工工作面承接等方向。目前部分高阶场景仍需结合具体业务做定制化设计，尚未作为统一标准能力全量实现。如 App 开发者有类似高阶需求，欢迎联系 Xinstall 客服团队进一步探讨或共同定向扩展。

参数还原 + 事件模型：把人物流量和任务流量放进同一张图里

问题：
传统事件模型大多围绕“曝光—点击—安装—注册—留存”搭建，它默认流量单位是“人”。但在【龙虾上岗】场景里，很多链路的最小单位其实变成了“任务”。如果后台仍然只记录用户是否安装，而不记录任务是如何发起、通过哪个 Agent 流转、最终在哪个节点被接住，就会导致数据解释始终停留在表层。

做法：
更合理的做法，是在数据仓和事件系统里构建一套“任务事件图”，把人物流量与任务流量同时纳入同一套视图中。建议至少增加以下字段维度：

• agent_platform
• agent_id
• workflow_id
• channelCode
• scene
• intent_type
• risk_level
• task_status
• handoff_stage

其中，task_status 可以描述任务是否成功推进、是否中断、是否需要人工接管；handoff_stage 则可以描述任务在什么阶段进入 App，例如“由 IM 转入”“由桌面工作面转入”“由 MCP 工具调用转入”。

带来的好处：
一旦这张图建起来，团队就不再只看到“一个企业用户安装了 App”，而能看到“某个数字员工工作流在第几步把任务交给了 App，用户是否继续完成，哪类任务最容易流失，哪类场景应该被优先优化”。这才是面向 Agent 时代的全链路归因，而不只是传统归因系统上多打几个埋点。

如果要进一步把 Agent 场景纳入站内知识和方法论，也可以自然参考 xinstall 在《智能体指令集 Skills.sh 发布：AI Agent 分发生态下的 App 归因新范式》里的那类思路：入口统一、参数不断、事件可回放，才有可能真正看清任务流量。

这件事和开发 / 增长团队的关系

面向开发 / 架构团队：先把任务流量当成一级公民

如果你负责开发或架构，接下来更应该优先做的是底层预留，而不是等业务放量后再补。
建议至少明确三件事：

• 预留任务上下文字段：如 agent_platform、workflow_id、channelCode、scene、risk_level。
• 首启路由支持参数驱动：不同数字员工入口进来的用户，不应该都落在同一个默认首页。
• 多终端 ID 策略提前统一：桌面、移动、IM、Web 工作面之间，如果没有一致的映射思路，后期几乎一定断链。

现在就能做的动作：

• 在安装与首启链路中增加任务参数解析位；
• 在事件系统中单列任务流量埋点口径；
• 给高价值场景做首启恢复页而不是统一首页。

面向产品 / 增长团队：入口定义权和归因解释权会重新洗牌

如果你负责产品或增长，那么【龙虾上岗】对你的意义，是入口权和解释权会发生变化。未来用户进入 App，未必先看到你的页面，而可能先被某个数字员工工作流承接；也未必先读完一段营销文案，而可能是先完成一个明确任务，再被导向 App。

这意味着产品团队需要重新定义“入口”：

• 是工作面入口，还是渠道入口？
• 是岗位入口，还是内容入口？
• 是人物流量，还是任务流量？
• 是用户自己发起，还是 Agent 代为发起？

增长团队则需要重新定义“有效来源”：

• 哪类数字员工入口值得持续加权？
• 哪类 Skill 模板带来的用户最像种子用户？
• 哪类企业工作流入口带来的不是下载，而是高价值任务？

现在可以立刻落地的建议有三条：

• 开发侧：先补字段，再补路由，别等量大了再修。
• 产品侧：为 2 到 3 个典型任务流量场景设计专属承接页。
• 增长侧：把“企业来源流量”拆成岗位与任务来源，而不是继续看大盘均值。

常见问题（FAQ）

“龙虾”进入企业后，为什么不能只停留在一个对话框里？

因为企业里的任务不是单点问答，而是跨系统、跨角色、跨工具的连续流程。对话框适合交流，但企业真正需要的是它能进入文档、浏览器、IM、表格、研发环境和内部系统，把任务推进下去，而不是只给建议。

为什么阿里云一直强调“工牌”而不是先强调模型能力？

因为企业最先需要解决的是身份和权限问题。一个 Agent 能接哪些系统、继承谁的权限、哪些动作必须授权、哪些行为必须留痕，这些都比“它是不是更聪明”更优先。没有身份体系，数字员工就无法进入组织流程。

workspace 里那些 SOUL、USER、AGENTS、SKILL 文件到底有什么用？

它们本质上是在把一个数字员工的行为规则、服务对象、任务逻辑、工具边界、记忆系统和岗位手册结构化。这样做的意义在于，让数字员工不靠一次性 Prompt 工作，而是靠一套可被管理、可被迭代、可被复用的定义体系工作。

企业为什么最终会把问题落到运行时和沙箱上？

因为只要 Agent 真的开始操作数据、调用工具、进入生产流程，企业关心的就不再只是“它会不会”，而是“出错怎么办、越权怎么办、日志怎么查、成本怎么控”。运行时和沙箱，本质上是在补企业环境最看重的确定性。

行业动态观察

从更长周期看，【龙虾上岗】真正代表的不是又一波 AI 工具热，而是企业软件的入口正在从“人找工具”慢慢转向“任务找工具”。数字员工、工作面、MCP、Skill、控制平面和 Runtime 这些词之所以突然重要，不是因为行业喜欢新名词，而是因为企业真的开始把 Agent 当作工作流中的执行单元来看待了。

这对 App 和 B 端团队的影响，会慢慢从“多了一个来源渠道”演变成“用户路径被重写”。入口不再只由页面决定，转化也不再只靠落地页解释，越来越多流量会先以任务形式进入，再以工作流形式被分发。在这个过程中，谁能先把任务入口、任务参数、任务事件图和首启承接补齐，谁就更有机会接住新一轮企业 AI 工作流红利。

所以现在确实是重构数据与归因体系的窗口期。过去你追踪的是人，现在你还要追踪任务；过去你优化的是页面，现在你还要优化工作流；过去你统计的是安装来源，现在你还要解释执行上下文。等企业数字员工真正大规模进入工作现场时，你会发现，最先决定谁能看懂增长、谁能接住转化的，恰恰就是今天要不要围绕【龙虾上岗】把这套归因体系提前重做一遍。