从 Coding Agent 到数字员工:AI 应用正在收敛成同一套系统架构

把云栖大会几个 Agent 产品的展台连着看下来,最反直觉的发现是:它们看起来分属完全不同的行业,长出来的却是同一套 OS。

Qoder 在做软件开发,QwenWork 在做知识工作,TinyFish 在做 Web Browser Agent,WonderClip 在做视频生产,OpenSearch 在做搜索和 Research。

把具体行业拿掉,它们的底层结构高度趋同:

上下文 → 规划 → 技能 → 执行 → 验证 → 记忆 → 业务结果
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

这是 Agent 产品正在收敛成的同一套系统架构。

⚠ 本文以阿里云生态(Qoder/QwenWork/TinyFish/WonderClip/OpenSearch)为现场样本。但下面这些架构判断,对自建场景、华为云、AWS、Azure、GCP 的 Agent 平台同样适用——七层栈是工程结构的收敛,不是某一朵云的私有结论。

一、Agent 的核心已经从”会回答”转向”能持续执行”

Chatbot 时代,系统的基本循环很简单:用户输入,模型输出。

Agent 时代,任务会持续几分钟、几小时甚至更长。它需要读取文件、使用浏览器、调用 API、执行代码、等待异步任务、检查结果、失败重试、保存状态。

一个 Prompt 加一个模型,装不下这些。

系统必须开始拥有 Runtime。

QwenWork 现场展示的 Legal Document Fill Out 任务很有代表性:它在独立 Sandbox Container 里运行,Agent 拥有虚拟桌面,可以调用文档处理工具。Marketing Content Generation 又叠加 PPT、图片、Lip Sync、Python、Pillow、FFmpeg 等不同工具。

Agent 的执行环境越来越接近一台可编程电脑——一个被沙箱保护、能调用多种运行时和工具、可以持续执行任务而不被中断的工作单元。Sandbox Container 提供隔离,虚拟桌面提供图形界面的可视化操作能力,工具调用让模型从”说话”走到”动手”。这个组合一旦稳定,Agent 才真正开始替代人的操作面,而不只是替代人的思考面。

二、Qoder 的”One Foundation”是产品信号,不是口号

Qoder 的展板有一句话:

One workbench. Four entries. One foundation.

上面承载 Workbench、CLI、IDE、JetBrains Plugin,还可以继续扩展 Cloud Agents、Agent SDK。

但真正值得关注的,是下面那一套共享的 Foundation。

如果每一种入口都重新实现一套 Agent,系统会快速失控。更合理的做法是把任务调度、权限、工具、Sandbox、Memory、Model Router、Verification 这些能力做成共用 Harness。

入口只负责适配不同用户和不同场景:CLI 给程序员、IDE 给开发者、Workbench 给非技术角色、JetBrains 给存量代码迁移场景、Cloud Agents 给异步触发、Agent SDK 给第三方集成。底下的调度、记忆、工具网关、验证、安全模型共享同一份。

这种复用的价值比表面看到的更大。一个组织里,Coding Agent 的 Sandbox 设计经验、Permission 设计经验、Recovery 经验,可以直接迁移到 Browser Agent、Content Agent、Ops Agent。重复造轮子最贵的不是开发成本,是出问题时不同 Agent 表现不一致带来的治理灾难——同一份代码,在 IDE Agent 里能改、在 CLI Agent 里也能改,但 Permission Model 不一样,审计日志格式不一样,出事时根本无法追溯。

三、一个通用 Agent Stack 至少有七层——以及每一层”自建 / 共享 / 待验证”的投资地图

把这几场内容抽象以后,我把 Agent Stack 拆成七层。下面这张表同时回答一个组织最实际的问题:哪些层该自建,哪些层可以直接共享开源或采购,哪些还看不清楚。

层	内容	投资判断(2026 现场观察)
1. Entry 入口	Web / CLI / IDE / IM / API / GitHub Issue / 企业工作台	适配层,不自建——选最适合自己用户的入口形态
2. Task 任务	Goal / Spec / Context / Acceptance / Priority / Budget	自建,但很薄——这是 Task 契约,写不好下游全乱
3. Context & Memory 上下文与记忆	企业知识、代码知识、历史任务、决策、用户偏好、当前状态	必须自建——Context 是组织资产,买不来
4. Planning & Skill 规划与技能	任务拆分、Skill 选择、模型选择、并行策略	Skill 自建,Planning 可借力——Skill 是护城河
5. Runtime & Tools 运行时与工具	Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / 企业 API	半自建——通用 Runtime 可借 Browser Use、Anthropic Agent SDK 等开源栈;企业 API 网关必须自建
6. Verification & Recovery 验证与恢复	测试、规则检查、结果评价、失败恢复、重试和回滚	自建——验证规则跟业务强绑定,买来的跑不动
7. Governance 治理	权限、Secrets、Audit、Cost、Policy、Human Approval	必须自建——且要走工程而非合规的视角设计

下面把七层的关键判断各拆一句:

第一层 Entry。Web、CLI、IDE、IM、API、GitHub Issue、企业工作台——都只是任务入口,本身不产生业务价值。

第二层 Task。Goal、Spec、Context、Acceptance Criteria、Priority、Budget 都应该属于 Task。一份合格的 Task 描述应该明确:目标、为什么做、完成后怎么算完成、优先级、能花多少钱。如果一个 Agent 系统连这六个字段都不齐,任务就开始在系统里飘。

第三层 Context & Memory。企业知识、代码知识、历史任务、决策、用户偏好、当前状态都在这里。Qoder 现场强调的 Repo Wiki、Knowledge Graph、Knowledge Cards 都是这一层的具体形态——把”分散的事实”变成”机器可召回的资产”。

第四层 Planning & Skill。系统判断任务如何拆,选择哪个可复用 Skill,哪些步骤需要强模型,哪些可以并行。这一层是 Agent 真正开始”思考”的地方,也是模型能力被密集调用的地方。

第五层 Runtime & Tools。Shell、Browser、Computer Use、Filesystem、Git、Database、MCP、企业 API 都属于这一层。它是 Agent 真正和外部世界接触的接缝。

第六层 Verification & Recovery。测试、规则检查、结果评价、失败恢复、重试和回滚。

第七层 Governance。权限、Secrets、Audit、Cost、Policy、Human Approval。还包括更细的几项——算法备案、模型可解释性、出错归责、第三方依赖管控、数据出境管控——这是国内强监管行业(医疗、金融、交通、媒体、公共安全)上线 Agent 跑不掉的几道硬约束。

模型贯穿其中,但模型不再等于整个 Agent 平台。这是过去两年最被低估的认知迁移——很多团队花了太多时间比较模型,真正决定系统能否上生产的是后六层。

四、Browser Agent 补的是 Agent 和现实世界之间的接口

TinyFish 这类产品很有代表性。

很多真实业务系统没有好用的 API,或者用户需要登录网站、操作动态页面、填写表单、切换页面、下载文件。传统自动化依赖 Playwright 或 Puppeteer 脚本,页面一改就失效。Browser Agent 让模型直接理解网页并执行动作。

这类能力补的是 Agent Runtime 的一个重要缺口:真实 Web。

一个外链提交 Agent、运营 Agent、采购 Agent、研究 Agent,都可能需要在网站里完成动作。

但这里真正困难的从来不是”能不能点按钮”。生产系统还要解决登录态——Cookie / Token 怎么管理、过期了怎么办;并发——一个任务里多个标签页同时操作怎么同步;失败恢复——页面崩溃、网络中断怎么续跑;重复提交——网络抖动后点击动作被重复执行怎么防;代理——地域 / IP 限制怎么绕;验证码——人机识别怎么过;权限——多账号隔离怎么做;最后还有”证明任务真的完成”——如何验证动作真的生效。

更深一层,间接提示词注入(Indirect Prompt Injection) 是 Browser Agent 在 2026 年最现实的安全威胁:OWASP 把 prompt injection 排在 2026 AI 威胁第一位,页面里塞一段隐藏文本就能诱导 Agent 把用户 Cookie 发出去。架构层面没有完整解,只能在 Sandbox、动作白名单、Ambient Credential 控制上做工程折中。

Browser Use 也必须被放进 Harness。只有 Demo 层能力远远不够。一个组织如果真要把 Browser Agent 用在生产里,光做这一层的成本就够重新做一套 RPA 系统。

所以 Browser Agent 看着像应用,实际是 Runtime 的一部分。

五、Verification 决定 Agent 能不能获得更高权限

Agent 系统有一个非常直接的规律:自主性越高,验证和治理必须越强。

一个只能起草邮件的 Agent,出错成本有限。

一个可以修改生产数据库、提交代码、发送广告预算、操作企业后台的 Agent,风险完全不同。

一个真正成熟的 Agent 平台不能只回答”能做什么”,还需要清楚表达:

它允许访问什么;
允许修改什么;
什么动作必须审批;
每一步留下什么审计记录;
失败以后如何恢复;
系统如何证明任务真的完成。

这里有一个工程化判断:如果一个 Agent 不能为它的每一步动作提供可验证的证据,它的自主权就应该被卡在”建议者”位置。换句话说,自主权是在合规框架内被验证能力逐步放大的,而不是被功能列表解锁的。一个 Agent 即使功能上能调 100 个 API,如果它不能证明每一次调用都达到了预期结果,在金融、医疗、跨境数据这类强监管场景里,它就只能停留在”建议者”角色。

这也是企业场景里 Governance 会越来越重要的原因——它不是合规部门的事,是工程部门必须一开始就和 Runtime 一起设计的能力。

六、Model Router 会变成基础调度器——但不是每层都要用最贵模型

多模型已经越来越常见。

一个有价值的多模型系统,不只是让用户在下拉框里选择 GPT、Qwen、Claude 或其他模型。

更合理的方式,是由系统根据任务自动路由。

复杂规划和架构判断用强模型;普通代码实现和文本整理用成本更低的模型;视觉任务使用多模态模型;批量分类走快速模型;关键 Review 再回到强模型。

这背后是一道朴素的工程判断:不同任务对模型的”能力-成本”曲线要求完全不同。让一个强模型去做批量分类,是浪费;让一个快速模型去做架构决策,会反复返工。Requesty 在 2026 年公开过一个经验数字:把 70% 的常规任务路由到 nano 模型、20% 到 mid-tier、10% 到 frontier 模型,平均单次查询成本可以下降 60% 到 80%,而质量几乎不损失——这是方向性示意,具体数字视任务类型和路由策略而定。

模型逐渐变成一种可调度计算资源。Agent Platform 负责在质量、速度、成本和风险之间做动态选择。

阶梯式路由的实操示例:一个 Agent 接到”分析竞品定价策略并给出建议”,它在”理解任务、拆分步骤、判断优先级”这一步用强模型;到”把 100 个 SKU 按价格区间分类”这一步切换到快速模型;等分类结果出来做综合判断时再切回强模型。

如果所有任务都用最贵模型,系统成本会很高;所有任务都用便宜模型,会在复杂节点上持续失败。真正的工程价值来自调度策略,而不是来自选哪个模型。

七、Skill 是连接通用 Runtime 和垂直业务的关键层——也是未来护城河

一个通用 Agent Runtime 本身没有业务价值。

它需要通过 Skill 进入真实场景。

Coding Skill 知道如何读 Repo、写 Spec、跑 Test、生成 PR。它要规定:什么时候必须先跑单测、什么时候允许跳过、PR 描述应该包含什么字段、什么改动必须人工 Review。

SEO Research Skill 知道如何找关键词、分析 Search Intent、验证竞争强度、生成内容大纲、确认页面已索引。它不是”做关键词调研”几个字,而是一整套流程。

E-commerce Creative Skill 知道 Brand、SKU、平台格式、合规和审核。它要清楚每个平台图片尺寸限制、违禁词、品类资质、投放前的最后一道审核流程。

Ops Skill 知道如何查看监控、日志、容器、数据库和回滚。它要能区分哪些报警可以自动响应、哪些必须人工介入、什么是安全回滚点。

Skill 不只是一份 SOP,它还是一份带版本管理、依赖管理、迭代管理、失败兜底的可执行资产——可以参照 Anthropic 在 2025 年 10 月推出的 Skills 协议,把每一类领域经验打包成 SKILL.md 文件夹,让不同 Agent 平台按需加载,而不是每次重新写一遍。

Skill 把通用执行能力和领域知识连接起来。

因此未来很多 AI 应用的护城河,会落在经过大量真实任务验证的 Domain Skills。这些 Skills 沉淀的是”在这个领域里,事情应该怎么做”——它不容易被新模型覆盖,不容易被新平台替代,反而会随着时间复利。

一个组织如果能持续积累 Skill,把每一次新任务变成 Skill 的增量更新,那它的 AI 能力就不是买来的,是长出来的。

八、行业镜头:四类组织落地的具体形态

下面四段不是叙事,是把抽象的”七层 Stack”映射到具体行业,看不同行业卡点差在哪里。

电信/运营商:套餐变更、政企专线开通、跨域故障定位都要穿越 BSS / OSS / CRM / 计费多个域。Agent 落地最大的痛点是跨域对账——一个 Agent 在 CRM 里改了用户套餐,必须同步告诉计费和 OSS,否则账期对不齐。Stack 上最值钱的层是第 5 层 Runtime & Tools(打通多域接口)加第 7 层 Governance(账务审计)。

金融/银行:风控、反洗钱、对账、监管报送都要求可解释、可审计、可追溯。一个反洗钱 Agent 每一次”放行”或”拦截”都必须能解释是基于哪条规则、哪段交易历史、哪份客户资料。Stack 上最值钱的是第 6 层 Verification(可解释证据链)和第 7 层 Governance(算法备案 + 数据出境管控)——这两层在国内金融监管框架下是上线硬约束,不是”加分项”。

制造:MES、ERP、QMS、SRM 长期彼此孤立,一个跨域决策(比如”产能不足要不要追加物料采购”)要在四个系统之间来回串。Agent 在制造业的实际形态是跨系统的编排层,而不是替代单系统。它同时读 ERP 的物料、QMS 的不良率、MES 的产能利用率、SRM 的供应商绩效,做一个综合判断。Stack 上最值钱的是第 5 层 Runtime(企业 API 网关)和第 3 层 Context(沉淀工艺知识、历史故障、车间经验)。

电商:大促跨域(下单、支付、库存、物流、客服),压测 / 库存一致 / 防薅羊毛 / 跨平台对账,Agent 在电商里最先落地的是创意运营(换商品图、换背景、配多语言素材)和客服坐席辅助。Stack 上最值钱的是第 4 层 Skill(每个平台 SKU / 渠道的合规和审核流程)和第 6 层 Verification(自动评价素材是否符合平台规范)。

四类组织的共同点:Stack 越往下越值得共享,越往上越值得自建。Runtime、Model Router、Tool Gateway 这种底层能力,几家一起共建或买成熟开源栈更划算;Skill、Context、Governance 必须自建,因为它绑业务、绑合规、绑组织资产。

九、最终产品可能表现得完全不同,底层却共享同一种 OS

一个 Coding Agent 和一个视频 Agent 的 UI、用户、商业模式都完全不同。

但底层都需要:Context、Task、Skill、Tools、Runtime、Verification、Memory、Governance,最后都要落到业务结果。

一个企业知识 Agent 和一个 Browser Agent 看起来也很远,但它们最后都要解决权限、状态、失败恢复和审计。

所以未来做多个 AI 产品时,值得区分两层。

上层保持垂直。 每个产品围绕一个完整 Job,拥有自己的用户体验、数据对象和业务指标。Coding Agent 的对象是 Repo 和 Code Review,视频 Agent 的对象是 Script 和 Asset,研究 Agent 的对象是 Source 和 Citation。它们各自的垂直深度不能用通用能力替代。

下层尽可能共享。 Agent Runtime、Model Router、Tool Gateway、Memory、Audit、Secrets、Evaluation 可以成为通用基础设施。

这既避免每个产品重复造轮子,也避免一开始就做一个巨大而没有用户的”万能 Agent 平台”——后者是过去两年很多团队踩过的大坑,试图一次做完所有场景,结果每个场景都没做到可用深度。

更稳的路径是先从具体任务验证价值,再把重复出现的底层能力抽出来。背后的判断:通用层只能从具体场景里长出来,不能从架构图里长出来。 一开始就设计”支持所有场景”的 Runtime,通常意味着没有为任何一个场景做到位。

反向自检 3 问(写完后拿来对照自己):

我们抽象出的 Runtime,是不是至少在两个具体场景里已经验证过通用性?
我们每一层的设计,有没有对应一个真实出过错的具体业务问题?
如果今天砍掉一半的预算,哪些层我们还会留下?如果答案是”context 和 skill”,方向对了;如果是”runtime 和网关”,可能要回炉。

这也是这次云栖大会留给我的一个长期判断:模型之上正在长出一层新的系统层,它不专属于某一款产品,而是逐渐变成 Agent 时代的 OS。谁先把这层 OS 沉淀扎实,谁就更可能在下一次产品迭代里吃到红利。

对决策者的启示

如果你是一家年营收在 50 亿以上的企业 AI 一号位(CDO/CIO/CTO),三件事可以现在就开始:

画出你组织当前的 Agent Stack 七层快照——不要急着买产品,先看清自己现在每一层是空白、外采,还是半成品。这张图本身就会暴露真正的瓶颈。
挑 1 个高 ROI 场景,先做完一整个垂直闭环——不要先建 Runtime。Coding Agent、客服辅助、研发助手任选一个,把 Context、Task、Skill、Verification 四层跑通,再去谈”建平台”。
把 Governance 提到工程层面,不要放在合规层面——权限、审计、可解释、出错归责、第三方依赖管控,从一开始就和业务 Agent 一起设计,而不是事后补。

你可能想问

Q1:这套七层 Stack,和 Gartner、IDC 提的多 Agent 编排框架有什么差别?
Gartner/IDC 关注的是组织层面多 Agent 的协同与治理;本文七层是单个 Agent 内部的工程结构。一个组织可以同时谈两层——单 Agent 走七层,多 Agent 之间走编排。Stack 是微观,编排是宏观。

Q2:为什么模型那一层没有单独占一层?
因为模型在 Agent 系统里是横向贯穿的资源,而非独占的一层。Model Router 把不同模型当作不同算力调度,和 Runtime 里的 Shell、Browser 是同等地位的”工具”。模型当然关键,但它不能独占 Agent 的复杂度。

Q3:小团队是不是应该跳过这一层,直接用 ChatGPT / Claude 这类端到端产品?
是的。年营收在 1 亿以下、组织复杂度低的团队,直接用现成的 Agent 产品(Browser Use、Manus、阿里云百炼 Agent 等)更划算。本文讨论的七层,是从”年营收 50 亿+ 的组织要不要建自己的 Agent 平台”这个问题出发的——小团队建平台是反向优化。

反向自检(给你,也给我自己)

下面三句话,任何一句在心里都点头,说明你可能正在被叙事带跑,而不是在用证据:

“只要模型够强,Agent 就会自己工作。”(模型是必要条件,不是充分条件。后六层决定能不能上生产。)
“我们需要一个万能 Agent 平台。”(这个念头的成本,大概率超过它在 6 个月内能带来的业务价值。)
“Skill 可以等模型稳定了再沉淀。”(Skill 是组织资产,晚一天沉淀,晚一天复利。)

如果上面三条都没点头,继续读下去。

文末引用说明(逐条出处 + 证据层级 + 立场标注)

“One workbench. Four entries. One foundation.” ——Qoder 官方展板与博客,2026 年云栖大会现场 + Alibaba Cloud Community 2026-08-31 发布的 Introducing Qoder 1.0 文中。证据层级:厂商主张(Alibaba 立场)。
QwenWork Legal Document Fill Out:Sandbox Container + 虚拟桌面 + 工具调用 ——阿里云 QwenWork 现场 demo,Alibaba Cloud Community 2026-09-25 文章。证据层级:厂商主张(Alibaba 立场)。
QoderWake 作为”数字员工”产品,2026-04-30 阿里发布 ——Baidu Encyclopedia Qoder 条目 + 阿里巴巴官方。证据层级:厂商主张(Alibaba 立场)。
OWASP 2026 威胁清单把 Prompt Injection 排在第一位 ——State of Browser Use, May 2026 综述(Michael Livs blog)。证据层级:第三方综合(OWASP 立场,行业共识)。
Requesty:阶梯路由 70/20/10 分配可降本 60-80% ——Requesty 官方博客,2026。证据层级:厂商主张(模型路由服务商立场,数字偏乐观,仅作方向性示意)。
Microsoft Agent Governance Toolkit (AGT),2026-04-02 开源 MIT ——niteagent.com 报道。证据层级:第三方综合(微软立场,但 AGT 是开源项目,数字可查)。
Anthropic Skills 协议:2025-10-16 发布,2025-12-18 开源为开放标准 ——Anthropic Engineering 博客 + Substack 综合 + Medium LM Po。证据层级:厂商主张 + 第三方综合(Anthropic 立场)。
IDC 预测 2026 年 40% 制造商将引入 AI 驱动排程 ——Groovy Web 2026 综述,引用 IDC 报告。证据层级:第三方综合(IDC 立场,数字方向性参考)。
Stripe “Minions” 每周合并 1,300+ PR,0 人写代码、全人工 Review ——Stripe 工程团队 Steve Kaliski 在 How I AI 2026-03-25 节目 + ByteMonk 2026-02-14 转述。证据层级:厂商主张(Stripe 立场,数字可参考,场景是 Stripe 工程内部,不可外推行业平均)。
BCG 2026 Applied AI Index:agentic 占 AI 总价值比 22%(2026)→ 39%(2030) ——BCG 公开发布报告。证据层级:第三方综合(咨询机构立场,数字方向性参考)。
Gartner 预测 2026 年 40% 企业应用嵌入任务型 AI Agent,对比 2025 年 <5% ——Paul Okhrem 2026 综述,引用 Gartner。证据层级:第三方综合(Gartner 立场,方向性参考)。
中国 CAC/NDRC/MIIT 联合发布《智能体标准化应用与创新发展实施意见》,2026-07-15 生效 ——Rimon Law 2026-07 月度中国 AI 法规简报。证据层级:第三方综合(法律机构立场,法规文件可查)。
TinyFish:融资 $47M,客户含 Google / DoorDash / Amazon,browser 冷启动 <250ms ——SwitchTools 2026 综述。证据层级:第三方综合(产品评测站立场,数字需在 TinyFish 官方核对)。

如果你正在评估企业内部 Agent 平台怎么建、哪些能力应该自建 / 采购 / 共享、哪些 Agent Runtime 复用价值最高,欢迎聊聊。我们做企业 AI 转型专项咨询——从 Agent 架构、Runtime 设计到 Skill 沉淀,帮你把”单点 Agent”沉淀成”组织级 Agent 平台”。

企业内训:面向管理层与业务骨干,3 天通识课 ¥9 万 / 场,把 Agent Stack 七层、Governance 工程视角、Skill 沉淀方法论拆给你团队。
专项咨询:90 分钟架构诊断 ¥3K 起,针对你组织当前的七层快照、空缺层、外采 vs 自建判断给出一份独立评估;深度陪跑按项目报价。
管理层分享与行业演讲:行业大会 / 闭门会 / 论坛主题分享,联系后定制议程。

合作邮箱:[email protected]。

延伸阅读:《AI 转型七步框架》,系统讲清楚企业落地 AI 的完整路径。

本地化要点(多语言翻译对照,IAIUSE 多语言策略·2026-08-09 约定)

翻译 19 语时,下述内容按目标语言市场本地化替换,结构/视觉不变:

中文稿内容	英文版	日文版	德文版	阿拉伯版
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch(保留产品名)	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch
阿里云 / 钉钉 / 飞书	Alibaba Cloud / AWS / GCP / Azure / Slack / Teams	アリババクラウド / AWS / GCP / Azure / Slack / Teams / Lark	Alibaba Cloud / AWS / GCP / Azure / Slack / Teams	علي بابا كلاود / AWS / Slack / Teams
中国电信/移动/联通(企业 Agent 部署场景)	AT&T / Verizon / T-Mobile	NTT / KDDI / ソフトバンク	Deutsche Telekom / Vodafone	STC / Etisalat
中国制造业代表企业(ERP/MES/QMS/SRM 案例)	GE / Honeywell / Rockwell	Toyota / Hitachi / NTT Data	Siemens / Bosch / SAP	SABIC / Aramco / STC
中国银行(金融案例)	JPMorgan / Goldman Sachs	Mitsubishi UFJ / SMFG	Deutsche Bank / Commerzbank	Emirates NBD / QNB
Sandbox Container / 虚拟桌面 / 工具调用	Sandbox Container / Virtual Desktop / Tool Calling	サンドボックス / 仮想デスクトップ / ツール呼び出し	Sandbox-Container / Virtueller Desktop / Werkzeugaufruf	حاوية معزولة / سطح مكتب افتراضي / استدعاء الأدوات
One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness
Browser Agent(浏览器智能体)	Browser Agent(保留)	ブラウザエージェント	Browser-Agent	وكيل المتصفح
Domain Skill / Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill	Domain Skill(保留)/ Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill	ドメインスキル / コーディングスキル / SEO リサーチスキル / Eコマースクリエイティブスキル / Ops スキル	Domain-Skill / Coding-Skill / SEO-Research-Skill / E-Commerce-Creative-Skill / Ops-Skill	مهارة المجال / مهارة البرمجة / مهارة بحث السيو / مهارة إبداع التجارة الإلكترونية / مهارة العمليات
Model Router	Model Router(保留)	モデルルーター	Model-Router	موجه النماذج
Verification & Recovery / Governance	Verification & Recovery / Governance(保留)	検証と復旧 / ガバナンス	Verifikation & Wiederherstellung / Governance	التحقق والاستعادة / الحوكمة
算法备案 / 数据出境	Algorithm Filing / Cross-border Data Transfer	アルゴリズム登記 / データ越境移転	Algorithmus-Registrierung / grenzüberschreitende Datenübertragung	تسجيل الخوارزميات / نقل البيانات عبر الحدود

说明:除上述本地化项外,文中全球性产品/概念(Context / Plan / Skill / Execute / Verify / Memory / Agent OS / 七层 Agent Stack / Harness)保持原文不译。其他 15 语种按 IAIUSE 三梯队执行:重点 5 语(中/英/德/日/阿)按上表本地化;顺带 9 语(西/法/葡/韩/俄/意/荷/波/土)保留 Qoder/QwenWork/TinyFish/WonderClip/OpenSearch 原名 + 替换本地代表企业;可选 5 语(瑞典/泰/越/乌克/印尼)保留原名占位。

关于本系列

「云栖观察」是 IAIUSE 推出的产业现场系列,从 2026 云栖大会出发,用研究者的视角拆解 AI 产业正在发生的真实变化——不追热点,只看下注的方向和证据的强度。

系列覆盖模型之上的系统层、Agent 落地、Context 资产、企业 AI 组织设计、AI 产品竞争单位迁移等话题,共约 10 篇。

我有近 8 年大型企业咨询与商业分析经验,曾任职于 IBM,参与过电信、金融、保险和制造业相关项目。此后继续在运营商产品、互联网产品和 AI 应用开发一线,从事需求分析、产品设计和跨团队落地。这个号背后其实是一个小团队——我和 1-2 位长期协作的同事,分头负责 AI 编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目,是我们几位共同交付过的。

研究资料库累计超过 200 篇。本系列的判断来自我的现场观察和行业交叉验证,带有明确的作者立场,不代表任何厂商观点。