Från Coding Agent till digital medarbetare: AI-applikationer konvergerar mot samma systemarkitektur

När man besöker de olika Agent-produktmontagen på Yunqi-konferensen finns det mest kontraintuitiva mönstret: produkterna verkar tillhöra helt olika branscher, men de har alla vuxit fram till samma OS.

Qoder arbetar med mjukvaruutveckling, QwenWork med kunskapsarbete, TinyFish som Web Browser Agent, WonderClip med videoproduktion och OpenSearch med sökning och Research.

Om man bortser från de specifika branscherna är deras underliggande struktur slående lik:

Kontext → Planering → Färdighet → Exekvering → Verifiering → Minne → Affärsresultat
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

Detta är den gemensamma systemarkitektur som Agent-produkter håller på att konvergera mot.

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

⚠ Denna artikel använder Alibaba Clouds ekosystem (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) som fallstudie. Arkitekturbedömningarna nedan gäller dock lika för egna miljöer, Huawei Cloud, AWS, Azure och GCP:s Agent-plattformar – sju-lagersstacken är en konvergens av teknisk struktur, inte en proprietär slutsats för en specifik molnleverantör.

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

1. Kärnan i en Agent har skiftat från “att kunna svara” till “att kunna utföra kontinuerligt”

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

Under chatbot-eran var systemets grundläggande cykel enkel: användaren ger input, modellen ger output.

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

I agent-erans utför en uppgift som kan ta minuter, timmar eller till och med längre. Den behöver läsa filer, använda webbläsare, anropa API:er, köra kod, vänta på asynkrona uppgifter, kontrollera resultat, försöka igen vid misslyckanden och spara tillstånd.

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

En enda prompt plus en modell räcker inte för allt detta.

系统必须开始拥有 Runtime。

Systemet måste börja ha en Runtime.

QwenWorks live-demonstration av uppgiften “Legal Document Fill Out” är representativ: den körs i en isolerad sandbox-container där Agent har tillgång till en virtuell desktop och kan anropa dokumenthanteringsverktyg. “Marketing Content Generation” bygger vidare på detta genom att kombinera olika verktyg som PPT, bilder, lip-sync, Python, Pillow och FFmpeg.

Agentens exekveringsmiljö närmar sig alltmer en programmerbar dator – en arbetsenhet som är skyddad av en sandbox, kan anropa flera runtime-miljöer och verktyg, samt kan utföra uppgifter kontinuerligt utan avbrott. Sandbox-containern tillhandahåller isolering, den virtuella desktopen ger visuell operativ förmåga för grafiska gränssnitt, och verktygsanrop låter modellen gå från att “prata” till att “agera”. Först när denna kombination stabiliseras börjar Agenten verkligen ersätta den mänskliga handlingsytan – inte bara den mänskliga tankeverksamheten.

Två, Qoders “One Foundation” är en produktvision, inte ett slagord

På Qoders monter står det:

One workbench. Four entries. One foundation.

Ovanpå finns Workbench, CLI, IDE, JetBrains Plugin, och det går att utöka med Cloud Agents och Agent SDK.

Men det verkligt intressanta är det gemensamma Foundation-lager som ligger under.

Om varje enskild entrypunkt skulle implementera sin egen Agent, skulle systemet snabbt bli ohållbart. Det vore betydligt smartare att bygga upp ett gemensamt Harness för uppgiftsplanering, behörigheter, verktyg, Sandbox, Memory, Model Router och Verification.

Varje entrypunkt ansvarar endast för att anpassa sig till olika användare och scenarier: CLI för programmerare, IDE för utvecklare, Workbench för icke-tekniska roller, JetBrains för legacykodmigrering, Cloud Agents för asynkron aktivering och Agent SDK för tredjepartsintegration. Under detta ligger gemensamma resurser för schemaläggning, minne, verktygsgateway, verifiering och säkerhetsmodell.

Värdet av denna återanvändning är betydligt större än vad som först framstår. De erfarenheter en organisation samlat på sig kring Sandbox-design, Permission-design och Recovery för Coding Agent överförs direkt till Browser Agent, Content Agent och Ops Agent. Kostnaden för att återuppfinna hjulet handlar inte primärt om utvecklingskostnader – det verkliga problemet är de styrningsmardrömmar som uppstår när olika agenter beter sig inkonsekvent. Samma kod kan redigeras i IDE Agent och CLI Agent, men när Permission Model skiljer sig åt och loggformaten i granskningsloggarna inte överensstämmer blir felsökning och spårbarhet i praktiken omöjlig.

Tre En generisk Agent Stack består av minst sju lager – samt en investeringskarta över “bygga själv / dela / validera” för varje lager

Efter att ha abstraherat dessa erfarenheter har jag delat in Agent Stack i sju distinkta lager. Tabellen nedan besvarar samtidigt den mest praktiska frågan varje organisation ställer sig: vilka lager bör byggas internt, vilka kan delas direkt via öppen källkod eller köpas in, och vilka fortfarande är oklara.

Nivå	Innehåll	Investeringsbedömning (2026 fältobservationer)
1. Entry	Webb / CLI / IDE / IM / API / GitHub Issue / Företagsarbetsstation	Anpassningslager, bygg inte eget — välj den form som passar dina användare bäst
2. Task	Mål / Specifikation / Kontext / Godkännande / Prioritet / Budget	Bygg eget, men tunt — detta är Task-kontraktet, brister här påverkar hela kedjan nedströms
3. Context & Memory	Företagskunskap, kodkunskap, historiska uppgifter, beslut, användarpreferenser, aktuellt tillstånd	Måste byggas eget — Kontext är en organisationsasset, kan inte köpas
4. Planning & Skill	Uppgiftsuppdelning, Skill-val, modellval, parallellstrategi	Bygg Skill själv, Planning kan lånas in — Skill är det egna skyddsvärdet

| 5. Runtime & Tools | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / Företags-API | Delvis egenutvecklad – Generiska runtime-miljöer kan utnyttja öppna stackar som Browser Use och Anthropic Agent SDK; företagets API-gateway måste byggas internt |
| 6. Verification & Recovery | Testning, regelgranskning, resultatutvärdering, feltolerans, återförsök och rollback | Egenutvecklad – Verifieringsregler är starkt kopplade till affärslogiken; externa lösningar fungerar inte för dessa ändamål |
| 7. Governance | Behörigheter, Secrets, Audit, Cost, Policy, Mänsklig godkännande | Måste egenutvecklas – Och bör designas ur ett ingenjörsperspektiv snarare än ett compliance-perspektiv |

Nedan bryts de kritiska bedömningarna för de sju lagren ned i enskilda satser:

Lager 1 – Entry. Webbgränssnitt, CLI, IDE, snabbmeddelanden, API, GitHub Issues, företagets arbetsplattform – dessa är endast startpunkter för uppgifter och genererar i sig inget affärsvärde.

Andra lagret: Task

Goal, Spec, Context, Acceptance Criteria, Priority och Budget bör alla ingå i en Task. En fullständig Task-beskrivning ska tydligt ange: målet, varför det ska genomföras, vad som räknas som färdigt, prioriteten samt tillgänglig budget. Om ett agentsystem saknar dessa sex fält redan från start kommer uppgiften att cirkulera runt utan att bli löst.

Tredje lagret: Context & Memory

Företagskunskap, kodkunskap, tidigare uppgifter, beslut, användarpreferenser och aktuellt tillstånd – allt detta hanteras på denna nivå. De konkreta uttrycksformerna som Qoder lyfte fram på plats – Repo Wiki, Knowledge Graph och Knowledge Cards – är alla specifika manifestationer av detta lager: att omvandla “spridda fakta” till “maskinellt återkallningsbara tillgångar”.

Fjärde lagret: Planning & Skill

Här bedömer systemet hur en uppgift ska delas upp, vilka återanvändbara Skills som kan appliceras, vilka steg som kräver kraftfulla modeller och vilka som kan köras parallellt. Detta lager är där agenten verkligen börjar “tänka”, och det är också här som modellens kapacitet utnyttjas som mest intensivt.

Femte lagret – Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP och Enterprise API hör hemma här. Det är här agenten faktiskt möter omvärlden.

Sjätte lagret – Verification & Recovery. Testning, regelgranskning, resultatvärdering, felhantering, återförsök och rollback.

Sjunde lagret – Governance. Behörigheter, Secrets, Audit, Cost, Policy, Human Approval. Hit hör också mer specifika krav – algoritmregistrering (算法备案), modellförklarbarhet, felansvarsfördelning, hantering av tredjepartsberoenden, datalekagekontroll (数据出境管控) – det här är de hårda villkoren som agentplattformar måste uppfylla för att kunna lanseras inom starkt reglerade branscher (sjukvård, finans, transport, media, allmän säkerhet).

Modellen löper genom hela stacken, men modellen är inte längre hela Agent-plattformen. Det här är det mest underskattade paradigmskiftet de senaste två åren – många team har ägnat alldeles för mycket tid åt att jämföra modeller, när det som egentligen avgör om ett system kan tas i produktion är de sex övre lagren.

Fyra. Browser Agent täcker luckorna mellan Agent och verkligheten

Produkter som TinyFish är representativa för den här kategorin.

Många verkliga affärssystem saknar bra API:er, eller så behöver användare logga in på webbplatser, interagera med dynamiska sidor, fylla i formulär, växla mellan flikar och ladda ner filer. Traditionell automatisering bygger på Playwright- eller Puppeteer-skript, som slutar fungera så fort sidan ändras. Browser Agent gör det möjligt för modellen att direkt förstå webbsidor och utföra handlingar.

Denna förmåga täcker en viktig lucka i Agent Runtime: den verkliga webben.

Ett extern länk-inlämning-agent, ett driftagent, ett inköpsagent eller ett forskningsagent kan alla behöva utföra åtgärder på webbplatser.

Men det som verkligen är svårt här har aldrig handlat om “kan vi klicka på knappar”. Produktionssystem måste också lösa inloggningsstatus – hur man hanterar cookies och tokens, vad man gör när de går ut; samtidighet – hur man synkroniserar när flera flikar opererar samtidigt inom en uppgift; feltolerans – hur man återupptar körningen när en sida kraschar eller nätverket bryts; dubbelinskickning – hur man förhindrar att åtgärder körs flera gånger efter nätverksproblem; proxy – hur man kringgår geografiska eller IP-begränsningar; captcha – hur man klarar mänsklig verifiering; behörigheter – hur man isolerar flera konton; och till sist “bevisa att uppgiften verkligen är slutförd” – hur man verifierar att åtgärderna faktiskt trädde i kraft.

深一层，间接提示词注入（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，犯错成本有限。

En Agent som kan modifiera produktionsdatabaser, skicka kod, hantera annonsbudgetar eller styra företagssystem medför en helt annan risknivå.

En verkligt mogen Agent-plattform kan inte bara svara på “vad kan göras”, utan måste tydligt förklara:

Vilka system den får åtkomst till;
Vad den tillåts ändra;
Vilka åtgärder som kräver godkännande;
Vilka granskningsspår som genereras för varje steg;
Hur systemet återställs vid fel;
Hur det kan bevisa att uppgiften faktiskt är slutförd.

Här kommer en avgörande teknisk bedömning: om en Agent inte kan leverera verifierbara bevis för varje enskild åtgärd, bör dess självständighet begränsas till rollen som “rådgivare”. Med andra ord, självständighet växer fram stegvis genom verifierad kompetens inom ett regelefterlevnadsramverk – inte genom fler funktioner på en lista. Även om en Agent tekniskt sett kan anropa 100 API:er, om den inte kan bevisa att varje anrop faktiskt uppnådde det förväntade resultatet, kan den i strikt reglerade sammanhang som finans, sjukvård eller gränsöverskridande datahantering endast inta rollen som “rådgivare”.

Det är därför Governance blir allt viktigare i företagssammanhang – det handlar inte om efterlevnad utan om en kapacitet som teknikavdelningen måste designa in i Runtime-miljön redan från början.

6. Model Router – Den nya grundläggande schemaläggaren, men inte alla lager behöver den dyraste modellen

Multimodellsystem blir allt vanligare.

Ett välfungerande multimodellsystem handlar inte om att låta användarna välja mellan GPT, Qwen, Claude eller andra modeller i en dropdown-meny.

Ett mer rimligt tillvägagångssätt är att systemet automatiskt routerar baserat på uppgiftens karaktär.

Avancerade modeller för komplex planering och arkitekturbeslut; kostnadseffektiva modeller för vanlig kodimplementation och textbearbetning; multimodala modeller för visuella uppgifter; snabba modeller för batchklassificering; och avancerade modeller återigen för kritiska granskningar.

Bakom detta ligger ett enkelt ingenjörsmässigt övervägande: olika uppgifter ställer helt olika krav på modellernas “kapacitet kontra kostnad”-kurva. Att använda en avancerad modell för batchklassificering är slöseri; att låta en snabb modell fatta arkitekturbeslut leder till upprepat merarbete. Requesty presenterade 2026 en erfarenhetssiffra: att skicka 70% av rutinuppgifterna till nano-modeller, 20% till mellanklass-modeller och 10% till frontier-modeller kan minska kostnaden per förfrågan med 60–80% samtidigt som kvaliteten knappt påverkas – detta är en riktlinje, de faktiska siffrorna varierar beroende på uppgiftstyp och routingstrategi.

Modeller blir alltmer en schemaläggningsbar beräkningsresurs. Agent Platform ansvarar för att göra dynamiska avvägningar mellan kvalitet, hastighet, kostnad och risk.

Stegviss Routning i Praktiken: Ett Konkret Exempel

En Agent får uppgiften “analysera konkurrenternas prissättningsstrategi och ge rekommendationer”. I steget “förstå uppgiften, dela upp i steg, bedöm prioritet” används en kraftfull modell. När det gäller “kategorisera 100 SKU:er efter prisintervall” växlar systemet till en snabbmodell. Och när kategoriseringen är klar och det är dags för en samlad bedömning, växlar agenten tillbaka till den kraftfulla modellen.

Om alla uppgifter hanteras med den dyraste modellen blir systemkostnaderna höga. Om alla uppgifter istället hanteras med en billig modell kommer systemet kontinuerligt att misslyckas vid komplexa beslutspunkter. Den verkliga tekniska och affärsmässiga nyttan kommer från en väldimensionerad schemaläggningsstrategi – inte från valet av en specifik modell.

Sjutton: Skill är den Kritiska Kopplingen mellan en Generisk Runtime och Vertikal Affärsverksamhet – och Framtidens Skyddsvall

En generisk Agent Runtime har i sig inget affärsvärde.

Den behöver ta sig in i verkliga scenarier genom Skills.

Coding Skill vet hur man läser ett Repo, skriver Spec-filer, kör Tester och genererar Pull Requests. Den definierar när det är obligatoriskt att först köra enhetstester, när det är tillåtet att hoppa över dem, vad en PR-beskrivning ska innehålla för fält, och vilka ändringar som kräver manuell granskning.

SEO Research Skill förstår hur man identifierar nyckelord, analyserar sökintention, verifierar konkurrensintensitet, genererar innehållsdispositioner och bekräftar att sidor har indexerats. Det handlar inte om några få ord som “gör nyckelordsundersökning” – det är en komplett, strukturerad process.

E-commerce Creative Skill handlar om förståelse för varumärken, SKU:er, plattformsformat, regelefterlevnad och granskningsprocesser. Det krävs kunskap om bildstorleksbegränsningar för respektive plattform, förbjudna termer, kategorikrav och det slutgiltiga godkännandet innan publicering.

Ops Skill innebär förmågan att övervaka system, granska loggar, hantera containrar, arbeta med databaser och genomföra återställningar. Personen måste kunna avgöra vilka larm som kan hanteras automatiskt och vilka som kräver manuell åtgärd, samt identifiera säkra återställningspunkter.

Ett Skill är långt ifrån bara en SOP – det är snarare en körbar tillgång med inbyggd versionshantering, beroendehantering, iterationshantering och fallback-mekanismer vid misslyckanden. Man kan tänka sig Anthropics Skills-protokoll från oktober 2025 som riktmärke: varje domänområde paketeras som en SKILL.md-mapp som olika agentplattformar kan ladda efter behov, istället för att behöva skrivas om från grunden varje gång.

Skills fungerar som en brygga mellan generella genomförandeförmågor och specialiserad domänkunskap.

Av den anledningen kommer framtidens AI-applikationers konkurrensfördelar att ligga i Domain Skills som validerats genom storskaliga verkliga uppgifter. Dessa Skills ackumulerar kunskap om “hur saker och ting bör utföras inom detta område” – de är svåra att ersätta med nya modeller, svåra att överföra till nya plattformar, och tenderar att växa i värde över tid.

En organisation som kontinuerligt bygger upp sina färdigheter och förvandlar varje ny uppgift till en inkrementell uppdatering av dessa färdigheter, har inte köpt sin AI-kompetens – den har odlat fram den.

Åtta. Branschperspektiv: Konkreta former för implementering inom fyra typer av organisationer

De fyra avsnitten nedan är inte narrativ – de kartlägger hur de abstrakta sju lagren i stacken tar sig uttryck i specifika branscher och var de olika branschernas flaskhalsar finns.

Telekomoperatörer: Paketbyten, aktivering av företags- och myndighetsabonnemang och felsökning över domängränserna kräver passage genom flera domäner – BSS, OSS, CRM och faktureringssystem. Den största smärtpunkten för Agent-implementering är cross-domänavstämning – när en Agent ändrar ett kundabonnemang i CRM måste den同步 meddela både faktureringssystemet och OSS, annars stämmer inte periodbokslutet. De mest värdefulla lagren i stacken är det femte lagret Runtime & Tools (som överbryggar gränssnitt mellan domäner) kombinerat med det sjunde lagret Governance (för revisionsspårning av ekonomisk data).

Finans/Bank: Riskhantering, penningtvättsbekämpning, avstämning och regulatorisk rapportering ställer alla krav på förklarbarhet, granskningsbarhet och spårbarhet. En penningtvättsbekämpande Agent måste för varje beslut om att “godkänna” eller “blockera” kunna redogöra för vilken regel, transaktionshistorik och kundinformation som ligger till grund för bedömningen. I stacken är det mest värdefulla lagret det sjunde – Verification (förklarbar beviskedja) – tillsammans med det åttonde lagret Governance (algoritmregistrering och gränsöverskridande datakontroll). Dessa två lager utgör i den inhemska finansiella regleringsramen absoluta krav för driftsättning, inte “meritförande”.

Tillverkning: MES, ERP, QMS och SRM har länge varit isolerade från varandra, och ett beslut som spänner över flera domäner (exempelvis “vid kapacitetsbrist – ska vi öka materialanskaffningen?”) kräver omständlig koordinering mellan fyra system. Agentens faktiska roll inom tillverkning är att fungera som ett orkestreringslager över systemgränserna, snarare än att ersätta enskilda system. Den läser samtidigt materialdata från ERP, defekttal från QMS, kapacitetsutnyttjande från MES och leverantörsprestanda från SRM för att fatta en samlad bedömning. I stacken är det mest värdefulla lagret det femte – Runtime (företagets API-gateway) – tillsammans med det tredje lagret Context (ackumulerad processteknik, historiska fel och produktionserfarenhet).

E-handel: Aktivering över domäner vid storskaliga kampanjer (beställning, betalning, lager, logistik, kundsupport), lasttest / lagersynkronisering / skydd mot bedrägerier / avstämning över plattformar. Inom e-handel var det 创意运营 (byte av produktbilder, byte av bakgrunder, anpassning av flerspråkigt material) och kundsupport som Agent-applikationerna först slog igenom på. På Stack-nivå är det mest värdefulla nivå 4 – Skill (efterlevnad och granskningsprocesser för varje plattforms SKU/kanal) och nivå 6 – Verification (automatisk verifiering av att material uppfyller plattformens riktlinjer).

Det gemensamma för alla fyra organisationstyper: ju längre ner i Stack desto mer lönsamt att dela, ju högre upp desto mer lönsamt att bygga själv. Basfunktioner som Runtime, Model Router och Tool Gateway är mer kostnadseffektiva att utveckla gemensamt eller köpa från mogna open source-stackar. Skill, Context och Governance måste däremot byggas internt eftersom de är direkt kopplade till affärsverksamhet, regelefterlevnad och organisationens tillgångar.

Nio. Slutprodukterna kan framstå helt olika, men delar samma underliggande OS

Ett Coding Agent och ett video Agent har helt olika UI, användare och affärsmodeller.

Men under huven behöver båda: Context, Task, Skill, Tools, Runtime, Verification, Memory och Governance – och måste till slut leverera mätbara affärsresultat.

En företagskunskapsagent och en webbläsaragent kan verka vara helt olika, men i slutändan måste båda hantera behörigheter, tillstånd, feltolerans och revision.

Därför är det värt att vid utveckling av flera AI-produkter skilja på två lager.

Behåll det övre lagret vertikalt. Varje produkt kretsar kring en komplett arbetsuppgift, med egen användarupplevelse, dataobjekt och affärsnyckeltal. För en kodningsagent handlar det om förvarsplatser och kodgranskning, för en videoagent om manus och resurser, och för en forskningsagent om källor och citat. Deras djup inom respektive område går inte att ersätta med generiska förmågor.

Gör det nedre lagret så gemensamt som möjligt. Agentkörningsmiljö, modellrouter, verktygsgateway, minne, revision, hemligheter och utvärdering kan utgöra en gemensam infrastruktur.

Detta undviker dels att varje produkt uppfinner hjulet på nytt, dels att man från start bygger en enorm “allsmäktig agentplattform” utan faktiska användare – vilket har varit en fälla för många team under de senaste två åren, där man försökte täcka alla tänkbara scenarier samtidigt och slutade med att ingen scenarie nådde tillräcklig användbar djupverkan.

En mer stabil väg framåt är att först validera värdet genom konkreta uppgifter, och sedan extrahera de underliggande förmågor som visar sig återkomma. Den bakomliggande principen är: Generiska lager kan endast växa fram från specifika scenarier, inte från ett arkitekturdiagram. Att från start försöka designa en Runtime som “stödjer alla scenarier” innebär typiskt sett att man inte levererar ordentligt för någon enskild scenarie.

Tre frågor för omvänd självkontroll (använd efter att du skrivit klart):

Har den Runtime vi har abstraherat verkligen validerats för generisk användbarhet i minst två specifika scenarier?
Finns det för varje lager vi har designat en verklig affärsproblem som faktiskt har uppstått som motsvarar denna design?
Om vi skulle minska budgeten med hälften i dag, vilka lager skulle vi behålla? Om svaret är “context och skill” är riktningen korrekt; om det är “runtime och gateway” kan det vara dags att gå tillbaka till ritbordet.

Det är också den långsiktiga slutsats jag tar med mig från Cloud Town-konferensen: Ovanpå modellerna håller ett nytt systemlager på att växa fram, som inte är knutet till någon enskild produkt utan gradvis blir den nya OS för agenteran. Den som först kan etablera detta OS-lager på ett robust sätt kommer sannolikt att dra nytta av nästa generations produkter迭代.

Implikationer för beslutsfattare

Om du är ansvarig för företagets AI-strategi (CDO/CIO/CTO) i ett företag med en årlig omsättning på över 5 miljarder, finns det tre saker du kan börja med nu:

慢慢学AI<001>

1. 描绘你组织当前 Agent Stack 的七层全景

不要急于采购产品，先厘清当前每一层的实际状态——是空白、依赖外部采购，还是处于半成品阶段。这张全景图本身就揭示了真正的瓶颈所在。

2. 选择 1 个高 ROI 场景，先完成一个完整的垂直闭环

不要一开始就着手构建 Runtime。从 Coding Agent、客服辅助或研发助手中选择一个场景，将 Context、Task、Skill、Verification 四层跑通，再考虑”平台化”建设。

3. 将 Governance 提升至工程层面，而非仅视为合规问题

权限管控、审计追溯、可解释性、出错归责、第三方依赖管理，这些从一开始就要与业务 Agent 一体化设计，而非事后补救。

你可能想问

Q1: 这套七层 Stack 与 Gartner、IDC 提出的多 Agent 编排框架有何区别？

Gartner/IDC 关注的是组织层面多 Agent 的协同与治理；本文七层是单个 Agent 内部的工程结构。一个组织可以同时推进两个层面——单 Agent 遵循七层设计，多 Agent 之间走编排。Stack 是微观，编排是宏观。

Q2: Varför har modellagret ingen egen plats i arkitekturen?

Anledningen är att modellen i ett agentsystem är en horisontellt genomgående resurs, inte ett separat lager. Model Router behandlar olika modeller som olika typer av beräkningskraft som ska schemaläggas – de har samma status som “verktyg” som Shell eller Browser i Runtime. Modellen är givetvis avgörande, men den kan inte ensam bära komplexiteten i en agent.

Q3: Borde mindre team hoppa över det här lagret och använda end-to-end-produkter som ChatGPT eller Claude?

Ja, det stämmer. För team med en årsomsättning under 100 miljoner yuan och låg organisatorisk komplexitet är det mer kostnadseffektivt att använda färdiga agentprodukter (t.ex. Browser Use, Manus, Alibaba Cloud Bailian Agent och liknande). De sju lager som diskuteras i den här artikeln utgår från frågan: “Ska en organisation med en årsomsättning på 5 miljarder yuan eller mer bygga sin egen agentplattform?” – för mindre team är det kontraproduktivt att bygga en egen plattform.

Omvänd egenkontroll (till dig, och till mig själv)

Följande tre påståenden – om du nickar instämmande till något av dem i dina tankar, kan det vara ett tecken på att du låter dig styras av narrativet snarare än av fakta:

De tre vanligaste заблужденияen kring AI-agenter i praktiken:

“Om modellen är tillräckligt kraftfull, kommer agenten att fungera av sig själv.” (Modellen är en nödvändig, men inte tillräcklig förutsättning. De sex översta lagren avgör om systemet kan produktionssättas.)
“Vi behöver en universal agentplattform.” (Kostnaden för denna vision överskrider sannolikt affärsvärdet den kan generera inom sex månader.)
“Vi kan vänta med att bygga upp Skills tills modellen stabiliserats.” (Skills är organisationsresurser – varje dag vi skjuter upp arbetet är en dag vi förlorar på sammansatt avkastning.)

Om du inte instämmer i alla tre punkterna ovan, fortsätt läsa.

Källor och evidensnivåer (individuella referenser med evidensklassificering och ståndpunktsmarkering)

Under denna rubrik kommer en detaljerad förteckning över samtliga källor som citeras i texten, komplett med bedömning av vetenskaplig trovärdighet och tydliga markeringar av respektive perspektiv.

“Ett arbetsbord. Fyra ingångar. En grund.” ——Qoder officiella monter och blogg, 2026 års Cloud World-konferens + Alibaba Cloud Community 2026-08-31 publicerade Introducing Qoder 1.0. Evidensnivå: Tillverkarpåstående (Alibabas position).
QwenWork Legal Document Fill Out: Sandbox Container + Virtuellt skrivbord + Verktygsanrop ——Alibaba Cloud QwenWork live-demo, Alibaba Cloud Community 2026-09-25 artikel. Evidensnivå: Tillverkarpåstående (Alibabas position).
QoderWake som “digital medarbetare”-produkt, lanserad av Alibaba 2026-04-30 ——Baidu Encyclopedia Qoder-post + Alibaba officiellt. Evidensnivå: Tillverkarpåstående (Alibabas position).
OWASP 2026 hotarlistan placerar Prompt Injection på första plats – Sammanfattning av “State of Browser Use, May 2026” (Michael Livs blogg). Evidensnivå: Tredjepartsöversikt (OWASP:s position, branschens konsensus).
Requesty: Stegvis routing med 70/20/10-fördelning kan minska kostnaderna med 60–80% – Requestys officiella blogg, 2026. Evidensnivå: Tillverkarpåstående (från modellroutingtjänstens perspektiv, siffrorna är något optimistiska, bör endast ses som en ungefärlig riktlinje).
Microsoft Agent Governance Toolkit (AGT), MIT-licensierad öppen källkod, 2026-04-02 – Rapporterat av niteagent.com. Evidensnivå: Tredjepartsöversikt (Microsofts position, men AGT är ett projekt med öppen källkod, siffrorna är verifierbara).
Anthropic Skills-protokollet: 2025-10-16 publicerat, 2025-12-18 öppen källkod som öppen standard ——Anthropic Engineering-blogg + Substack-sammanfattning + Medium LM Po. Evidensnivå: Tillverkarens påståenden + tredjepartssammanfattning (Anthropics position).
IDC förutspår att 40 % av tillverkarna kommer att införa AI-driven schemaläggning 2026 ——Groovy Web 2026-översikt, med referens till IDC-rapport. Evidensnivå: Tredjepartssammanfattning (IDC:s position, siffrorna är riktgivande).
Stripe “Minions” slår samman 1 300+ PR varje vecka, 0 personer skriver kod, helt manuell Review ——Stripe:s ingenjörsteam Steve Kaliski i How I AI 2026-03-25 + ByteMonk 2026-02-14 vidarebefordran. Evidensnivå: Tillverkarens påståenden (Stripes position, siffrorna är referensvärden, scenen är Stripes interna ingenjörsarbete och kan inte generaliseras till branschgenomsnittet).
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: finansiering $47M, kunder inklusive Google/DoorDash/Amazon, browser kallstart <250ms — SwitchTools 2026 översikt. Evidensnivå: tredjepartsöversikt (produktrecensionssajt, siffror bör verifieras mot TinyFish officiella källor).

Om du utvärderar hur du bygger en intern Agent-plattform för företaget, vilka förmågor som bör byggas internt / köpas in / delas, och vilka Agent Runtime-komponenter som har högst återanvändningsvärde, är du välkommen att höra av dig. Vi erbjuder specialiserad rådgivning inom företags AI-transformation — från Agent-arkitektur och Runtime-design till Skill-ackumulering, och hjälper dig att utveckla “enskilda Agenter” till en “organisatorisk Agent-plattform”.

Företagsintern utbildning

Riktad till ledning och nyckelpersoner – en 3-dagars översiktskurs för 90 000 yuan per tillfälle. Vi delar upp Agent Stack i sju lager, ingenjörsperspektiv på Governance samt metodik för kunskapsackumulering och färdighetsöverföring till ditt team.

Specialiserad konsultation

90-minuters arkitekturdiagnostik från 3 000 yuan. Du får en oberoende utvärdering av din organisations nuvarande ögonblicksbild i sju lager, luckor i arkitekturen samt en analys av Make vs. Buy. Djupgående genomförandestöd offereras per projekt.

Ledningspresentationer och branschföredrag

Teman på branschkonferenser, inbjudna möten eller forum – kontakta oss för en anpassad agenda.

Kontakta oss: [email protected]

Rekommenderad läsning

AI-transformationsramverk i sju steg – en systematisk genomgång av hela vägen för företag som implementerar AI.

Lokalanpassningsprinciper (flerspråkig översättningsjämförelse, IAIUSE:s flerspråkiga strategi · överenskommelse 2026-08-09)

Vid översättning till 19 språk ska nedanstående innehåll lokaliseras för målspråksmarknaden, medan struktur och visuellt bevaras:

中文稿内容	英文版	日文版	德文版	阿拉伯版	瑞典语版
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	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch（produktnamnen bevaras）

Webbläsaragent

| Domänkunskap / Kodningsfärdighet / SEO-forskningsfärdighet / E-handels kreativ färdighet / Driftsfärdighet | Domänkunskap / Kodningsfärdighet / SEO-forskningsfärdighet / E-handels kreativ färdighet / Driftsfärdighet | ドメインスキル / コーディングスキル / SEO リサーチスキル / Eコマースクリエイティブスキル / Ops スキル | Domain-Skill / Coding-Skill / SEO-Research-Skill / E-Commerce-Creative-Skill / Ops-Skill | مهارة المجال / مهارة البرمجة / مهارة بحث السيو / مهارة إبداع التجارة الإلكترونية / مهارة العمليات |

Model Router	Model Router(保留)	モデル路由器	Model-Router	موجه النماذج
Verifiering & Återställning / Governance	Verifiering & Återställning / Governance (bevaras)	Verifiering och återställning / Governance	Verifiering & Återställning / Governance	Verifiering och återställning / Governance
Algoritmregistrering / Gränsöverskridande dataöverföring	Algoritmregistrering / Gränsöverskridande dataöverföring	Algoritmregistrering / Gränsöverskridande dataöverföring	Algoritmregistrering / Gränsöverskridande dataöverföring	Algoritmregistrering / Gränsöverskridande dataöverföring

Om denna serie

“Cloud Summit Insights” är en serie branschrapporter från IAIUSE, lanserad i samband med Cloud Summit 2026. Här granskar vi de verkliga förändringarna inom AI-industrin ur ett forskarperspektiv – utan att jaga kortsiktiga trender, med fokus på riktningen för satsningar och bevisens styrka.

Serien täcker in systemlager ovanför modeller, agentimplementering, context-tillgångar, organisation av företags-AI och förändringar i konkurrensenheter för AI-produkter. Totalt omfattar serien cirka tio artiklar.

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

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