Von Coding Agent zu digitalen Mitarbeitern: KI-Anwendungen konvergieren zu einem einheitlichen Systemarchitektur

Wenn man die Stände verschiedener Agent-Produkte auf der Yunqi-Konferenz nacheinander besucht, ergibt sich eine der überraschendsten Erkenntnisse: Obwohl sie scheinbar völlig unterschiedlichen Branchen angehören, haben sie sich zu ein und demselben Betriebssystem entwickelt.

Qoder ist im Softwareentwicklungsbereich tätig, QwenWork im Wissensarbeitssektor, TinyFish als Web-Browser-Agent, WonderClip in der Videoproduktion und OpenSearch im Bereich Suche und Research.

Entfernt man die branchenspezifischen Details, zeigt sich eine bemerkenswerte Konvergenz in der zugrundeliegenden Struktur:

Kontext → Planung → Fähigkeiten → Ausführung → Verifizierung → Erinnerung → Geschäftsergebnis
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

Dies ist das einheitliche Systemarchitektur-Muster, zu dem Agent-Produkte derzeit zusammenlaufen.

⚠ Dieser Artikel nutzt das Alibaba-Cloud-Ökosystem (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) als Praxisfall. Die untenstehenden architektonischen Einschätzungen gelten jedoch gleichermaßen für selbstgebaute Szenarien sowie für Agent-Plattformen von Huawei Cloud, AWS, Azure und GCP – das Seven-Layer-Stack ist eine Konvergenz ingenieurtechnischer Strukturen, keine proprietäre Schlussfolgerung einer einzelnen Cloud.

1. Der Kern von Agenten hat sich von „kann antworten” zu „kann kontinuierlich ausführen” verlagert

In der Chatbot-Ära war der grundlegende Systemzyklus denkbar einfach: Nutzereingabe, Modellausgabe.

Im Agent-Zeitalter können Aufgaben mehrere Minuten, Stunden oder sogar länger dauern. Der Agent muss Dateien lesen, Browser bedienen, APIs aufrufen, Code ausführen, auf asynchrone Tasks warten, Ergebnisse prüfen, bei Misserfolg erneut versuchen und Zustände speichern.

Ein einzelnes Prompt und ein einzelnes Modell reichen dafür nicht mehr aus.

Das System muss nun über eine Runtime verfügen.

慢慢学AI（持续更新）

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.

Oben befinden sich Workbench, CLI, IDE und JetBrains Plugin, mit der Möglichkeit zur Erweiterung um Cloud Agents und Agent SDK.

Doch was wirklich bemerkenswert ist, liegt darunter – das gemeinsam genutzte Foundation-Modul.

Wenn jede Schnittstelle einen eigenen Agent neu implementieren würde, geriete das System schnell außer Kontrolle. Ein deutlich sinnvollerer Ansatz besteht darin, Fähigkeiten wie Task-Dispatching, Berechtigungen, Tools, Sandbox, Memory, Model Router und Verification in einem gemeinsamen Harness zu bündeln.

Die einzelnen Einstiegspunkte übernehmen lediglich die Anpassung an verschiedene Benutzer und Szenarien: CLI richtet sich an Programmierer, IDE an Entwickler, Workbench an nicht-technische Rollen, JetBrains an Migrationsszenarien für Bestandscode, Cloud Agents an asynchrone Auslöser und Agent SDK an Drittanbieter-Integrationen. Die darunterliegenden Mechanismen für Dispatching, Memory, Tool-Gateway, Verification und Sicherheitsmodelle hingegen werden von allen gemeinsam genutzt.

Der Wert dieser Wiederverwendung geht weit über das Offensichtliche hinaus. Die Design-Erfahrungen für Sandboxes, Berechtigungsmodelle und Recovery-Mechanismen, die ein Team für Coding Agents entwickelt hat, lassen sich unmittelbar auf Browser Agents, Content Agents oder Ops Agents übertragen. Das Kostenproblem beim wiederholten Rad-neu-Erfinden liegt weniger in den Entwicklungskosten selbst, sondern in den Governance-Katastrophen, die auftreten, wenn verschiedene Agents unterschiedlich agieren. Ein und derselbe Code lässt sich im IDE Agent ändern und im CLI Agent ebenfalls modifizieren – doch wenn die Permission Modelle und Audit-Log-Formate inkonsistent sind, wird eine Nachverfolgung im Problemfall praktisch unmöglich.

Drei: Ein通用 Agent Stack umfasst mindestens sieben Schichten – dazu eine Investitionslandkarte für „Self-Built / Shared / TBD” auf jeder Ebene

Wenn man diese Erkenntnisse abstrahierend zusammenfasst, lässt sich der Agent Stack in sieben Layer untergliedern. Die folgende Tabelle beantwortet gleichzeitig die drängendste Frage einer jeden Organisation: Welche Schichten sollten selbst aufgebaut werden, welche lassen sich direkt aus Open-Source-Lösungen oder Zukäufen übernehmen, und welche bleiben vorerst ungewiss.

Investment Judgment (2026 Feldbeobachtung)

Schicht	Inhalt	Investitionsurteil (2026 Feldbeobachtung)
1. Entry	Web / CLI / IDE / IM / API / GitHub Issue / Enterprise Dashboard	Adaptionsschicht, nicht selbst aufbauen – die Entry-Form wählen, die für die eigenen Nutzer am besten geeignet ist
2. Task	Goal / Spec / Context / Acceptance / Priority / Budget	Selbst aufbauen, aber schlank – Task-Verträge sind entscheidend; schlechte Formulierung bringt die gesamte downstream-Implementierung durcheinander
3. Context & Memory	Unternehmenswissen, Code-Wissen, Historische Tasks, Entscheidungen, Nutzerpräferenzen, Aktueller Zustand	Muss selbst aufgebaut werden – Kontext ist Organisationsvermögen und lässt sich nicht zukaufen
4. Planning & Skill	Task-Zerlegung, Skill-Auswahl, Modell-Auswahl, Parallelisierungsstrategie	Skills selbst aufbauen, Planning kann zugekauft werden – Skills sind der Burggraben

| 5. Runtime & Tools 运行时与工具 | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / 企业 API | Semi-Selbstbau – Universelle Runtime-Lösungen lassen sich auf Open-Source-Stacks wie Browser Use oder Anthropic Agent SDK stützen; ein unternehmenseigenes API-Gateway ist jedoch unverzichtbar |
| 6. Verification & Recovery 验证与恢复 | Tests, Regelprüfung, Ergebisauswertung, Fehlerbehebung, Wiederholung und Rollback | Selbstbau – Verifizierungsregeln sind eng mit dem Geschäft verknüpft; gekaufte Lösungen stoßen hier an ihre Grenzen |
| 7. Governance 治理 | Berechtigungen, Secrets, Audit, Kosten, Richtlinien, Human Approval | Zwingend Selbstbau – und zwar aus ingenieurtechnischer Perspektive, nicht aus Compliance-Sicht |

Im Folgenden werden die wesentlichen Entscheidungskriterien für jede der sieben Schichten einzeln erläutert:

Erste Schicht: Entry. Web, CLI, IDE, IM, API, GitHub Issue, Unternehmensorbeitsplätze – all das sind lediglich Zugangswege für Aufgaben und erzeugen für sich allein keinen geschäftlichen Mehrwert.

Ebene 2 – Task. Goal, Spec, Context, Acceptance Criteria, Priority und Budget sollten alle zu Task gehören. Eine vollständige Task‑Beschreibung muss klarstellen: das Ziel, den Grund für die Durchführung, was als erledigt gilt, die Priorität und wie viel Budget zur Verfügung steht. Wenn ein Agent‑System nicht einmal diese sechs Felder vollständig besitzt, beginnt die Aufgabe im System zu „herumirren“.

Ebene 3 – Context & Memory. Unternehmenswissen, Code‑Wissen, vergangene Tasks, Entscheidungen, Benutzerpräferenzen und der aktuelle Zustand werden hier verwaltet. Die von Qoder vor Ort betonten Repo Wiki, Knowledge Graph und Knowledge Cards sind konkrete Ausprägungen dieser Ebene – sie verwandeln „verstreute Fakten“ in „maschinell abrufbare Assets“.

Ebene 4 – Planning & Skill. Das System entscheidet, wie ein Task zerlegt wird, welcher wiederverwendbare Skill gewählt wird, welche Schritte ein leistungsstarkes Modell erfordern und welche parallel ausgeführt werden können. Diese Ebene ist der Ort, an dem der Agent wirklich zu „denken“ beginnt und die Modellfähigkeiten intensiv genutzt werden.

第五层 Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP und Enterprise-APIs gehören alle zu dieser Schicht. Sie ist die Nahtstelle, an der der Agent tatsächlich mit der Außenwelt interagiert.

Sechste Schicht Verification & Recovery. Tests, Regelprüfungen, Ergebnisauswertung, Fehlerbehebung, Wiederholungen und Rollbacks.

Siebte Schicht Governance. Berechtigungen, Secrets, Audit, Kosten, Richtlinien, menschliche Genehmigung. Hinzu kommen weitere feinkörnige Aspekte – 算法备案 (Algorithmusregistrierung), Modellinterpretierbarkeit, Fehlerzurechnung, Management von Drittanbieter-Abhängigkeiten, 数据出境管控 (Kontrolle grenzüberschreitender Datenflüsse) – dies sind unverzichtbare harte Auflagen für stark regulierte Branchen (Gesundheitswesen, Finanzen, Verkehr, Medien, öffentliche Sicherheit), wenn sie Agent-Lösungen einführen wollen.

Modelle durchziehen all diese Schichten, aber das Modell ist nicht mehr gleichbedeutend mit der gesamten Agent-Plattform. Dies ist die in den letzten zwei Jahren am meisten unterschätzte Erkenntnis – viele Teams haben zu viel Zeit mit Modellvergleichen verbracht, während die entscheidenden Faktoren für die Produktionsreife in den anderen sechs Schichten liegen.

Vier Browser Agenten schließen die Lücke zwischen Agent und realer Welt

Produkte wie TinyFish sind hier besonders repräsentativ.

Browser Agent：弥合自动化与真实Web交互的桥梁

在许多实际业务系统中，要么缺乏友好的API接口，要么需要用户登录网站、操作动态页面、填写表单、切换页面或下载文件。传统的自动化方案依赖Playwright或Puppeteer脚本，一旦页面结构发生变化就会失效。Browser Agent则让AI模型能够直接理解网页并执行相应动作。

这种能力填补了Agent Runtime的一个关键缺口：真实的Web环境。

无论是外链提交Agent、运营Agent、采购Agent还是研究Agent，都可能在网站上需要完成各种操作动作。

但这里真正困难的从来不是”能否点击按钮”。生产级系统还需要解决以下问题：

登录态管理：Cookie/Token如何管理，过期后如何处理
并发控制：一个任务中多个标签页同时操作时如何同步
失败恢复：页面崩溃或网络中断后如何续跑
重复提交防护：网络抖动后点击动作被重复执行如何防止
代理访问：地域/IP限制如何绕过
验证码处理：人机识别如何通过
权限隔离：多账号如何隔离
任务验证：如何证明任务真的完成了——即如何验证动作确实生效

Eine Ebene tiefer ist Indirect Prompt Injection die realistischste Sicherheitsbedrohung für Browser Agents im Jahr 2026: OWASP führt Prompt Injection als Nummer eins der AI-Bedrohungen 2026 auf – ein versteckter Textabschnitt auf einer Seite reicht aus, um den Agent dazu zu bringen, die Cookies des Nutzers abzusenden. Auf Architekturebene gibt es keine vollständige Lösung; man kann nur durch Engineering-Kompromisse bei Sandbox, Action-Whitelist und Ambient Credential Control gegensteuern.

Browser Use muss ebenso in den Harness eingeordnet werden. Demo-Level-Fähigkeiten allein sind bei weitem nicht ausreichend. Wenn eine Organisation Browser Agents tatsächlich produktiv einsetzen will, sind die Kosten für diese eine Ebene allein schon hoch genug, um ein gesamtes RPA-System neu aufzubauen.

Daher sieht ein Browser Agent zwar aus wie eine Anwendung, ist aber tatsächlich ein Teil der Runtime.

Fünf, Verification bestimmt, ob ein Agent höhere Rechte erhält

Es gibt eine sehr direkte Gesetzmäßigkeit in Agent-Systemen: Je höher die Autonomie, desto stärker müssen Verification und Governance sein.

Ein Agent, der nur E-Mail-Entwürfe verfassen kann, hat begrenzte Fehlerkosten.

Ein Agent, der Produktionsdatenbanken ändern, Code einreichen, Werbebudgets verwalten oder betriebliche Backend-Systeme bedienen kann, stellt ein völlig anderes Risikoniveau dar.

Eine wirklich ausgereifte Agent-Plattform beantwortet nicht nur die Frage „Was kann ich tun?”, sondern macht auch transparent:

Welche Zugriffe sind gestattet;
Welche Änderungen sind erlaubt;
Welche Aktionen einer Genehmigung bedürfen;
Welche Prüfprotokolle bei jedem Schritt hinterlassen werden;
Wie nach einem Fehler wiederhergestellt wird;
Wie das System die tatsächliche Aufgabenerfüllung nachweist.

Eine entscheidende ingenieurtechnische Erkenntnis lautet: Wenn ein Agent für jede seiner Aktionen keine überprüfbaren Belege liefern kann, sollte sein Autonomiegrad auf die Rolle eines „Beraters” beschränkt bleiben. Mit anderen Worten – Autonomie wird schrittweise im Rahmen eines Compliance-Frameworks durch verifizierte Fähigkeiten erweitert, nicht durch das Freischalten weiterer Funktionen. Selbst wenn ein Agent technisch 100 APIs aufrufen könnte, bleibt er in stark regulierten Bereichen wie Finanzen, Medizin oder grenzüberschreitendem Datenaustausch auf die Rolle des „Beraters” beschränkt, solange er nicht nachweisen kann, dass jeder einzelne Aufruf das erwartete Ergebnis erzielt hat.

Genau deshalb wird Governance in Enterprise-Szenarien eine immer wichtigere Rolle spielen – es ist nicht nur Sache der Compliance-Abteilung, sondern eine Kernfähigkeit, die die Engineering-Teams von Anfang an gemeinsam mit der Runtime gestalten müssen.

Sechs, Model Router wird zum fundamentalen Scheduler – aber nicht jede Schicht braucht das teuerste Modell

Mehrere Modelle werden zunehmend zur Normalität.

Ein wertvolles Multi-Modell-System bedeutet nicht nur, dass Nutzer in einem Dropdown-Menü zwischen GPT, Qwen, Claude oder anderen Modellen wählen.

Der sinnvollere Ansatz ist, dass das System Aufgaben automatisch weiterleitet.

Komplexe Planungen und Architekturentscheidungen erledigt ein starkes Modell; alltägliche Code-Implementierungen und Textorganisation übernehmen kostengünstigere Modelle; visuelle Aufgaben erfordern multimodale Modelle; Massenklassifizierungen laufen über schnelle Modelle; kritische Reviews fallen wieder an ein starkes Modell zurück.

Dahinter steckt eine schlichte ingenieurtechnische Überlegung: Unterschiedliche Aufgaben stellen völlig unterschiedliche Anforderungen an die „Kompetenz-Kosten”-Kurve eines Modells. Ein starkes Modell für Massenklassifizierungen einzusetzen, ist Verschwendung; ein schnelles Modell für Architekturentscheidungen heranzuziehen, führt zu endlosen Nacharbeiten. Requesty hat 2026 eine Erfahrungszahl veröffentlicht: Wenn 70 % der Routineaufgaben auf Nano-Modelle, 20 % auf Mid-Tier-Modelle und 10 % auf Frontier-Modelle geroutet werden, sinken die durchschnittlichen Kosten pro Abfrage um 60 % bis 80 %, bei nahezu keinem Qualitätsverlust – dies dient als Richtungsangabe, die konkreten Zahlen variieren je nach Aufgabentyp und Routing-Strategie.

Modelle entwickeln sich zunehmend zu einem dispatchbaren Compute-Resource. Die Agent Platform übernimmt die dynamische Auswahl zwischen Qualität, Geschwindigkeit, Kosten und Risiko.

Praktisches Beispiel für gestaffeltes Routing

Ein Agent erhält die Aufgabe, „Wettbewerber-Preisstrategien zu analysieren und Empfehlungen zu geben”. Für den Schritt „Aufgabe verstehen, Schritte aufteilen, Prioritäten bewerten” nutzt er ein leistungsstarkes Modell. Wenn es darum geht, „100 SKUs nach Preiskategorien zu klassifizieren”, wechselt er zu einem schnellen Modell. Sobald die Klassifizierung abgeschlossen ist und eine的综合判断 erforderlich ist, schaltet er zurück zum leistungsstarken Modell.

Wenn alle Aufgaben mit dem teuersten Modell erledigt würden, wären die Systemkosten prohibitiv hoch. Würde man hingegen bei allen Aufgaben ein günstiges Modell einsetzen, würde man bei komplexen Entscheidungspunkten kontinuierlich scheitern. Der eigentliche ingenieurtechnische Mehrwert liegt in der调度策略 – nicht in der Frage, welches Modell man wählt.

Sieben – Skill als entscheidende Vermittlungsschicht zwischen generischem Runtime und vertikalem Geschäft

Ein generischer Agent Runtime besitzt keinen inhärenten Geschäftswert.

Er muss durch Skill in reale Anwendungsszenarien eintreten.

Coding Skill weiß, wie man Repos liest, Spezifikationen verfasst, Tests ausführt und Pull Requests generiert. Es legt fest: Wann müssen zwingend Komponententests zuerst ausgeführt werden, wann ist ein Überspringen zulässig, welche Felder muss die PR-Beschreibung enthalten, welche Änderungen erfordern zwingend einen menschlichen Review.

SEO Research Skill weiß, wie man Keywords identifiziert, Search Intent analysiert, Wettbewerbsintensität verifiziert, Content-Outlines generiert und sicherstellt, dass Seiten indexiert wurden. Es handelt sich nicht einfach um „Keyword-Recherche betreiben”, sondern um einen整个流程 – von der initialen Analyse bis zur abschließenden Validierung.

E-commerce Creative Skill umfasst Kenntnisse über Marken, SKUs, Plattformformate, Compliance und Prüfverfahren. Es muss die Bildgrößenbeschränkungen jeder Plattform, verbotene Begriffe, Kategoriezulassungen sowie den abschließenden Prüfprozess vor der Schaltung kennen.

Ops Skill weiß, wie man Überwachung, Logs, Container, Datenbanken und Rollbacks überprüft. Es muss unterscheiden können, welche Alarme automatisch reagieren können und welche einen manuellen Eingriff erfordern, sowie was als sicherer Rollback-Punkt gilt.

Ein Skill ist nicht nur ein SOP-Dokument, sondern ein ausführbares Asset mit Versionskontrolle, Abhängigkeitsmanagement, Iterationssteuerung und Failback-Mechanismen – angelehnt an das Skills-Protokoll, das Anthropic im Oktober 2025 eingeführt hat. Dabei wird jede Domänenerfahrung als SKILL.md-Ordner gepackt, sodass verschiedene Agent-Plattformen diese nach Bedarf laden können, anstatt sie jedes Mal neu erstellen zu müssen.

Skills verbinden allgemeine Ausführungsfähigkeiten mit domänenspezifischem Wissen.

Daher wird der Burggraben vieler zukünftiger KI-Anwendungen in umfangreich mit realen Aufgaben validierten Domain Skills liegen. Diese Skills enthalten das Wissen darüber, „wie man in diesem Bereich Dinge erledigt” – sie lassen sich nicht leicht durch neue Modelle ersetzen, nicht einfach von neuen Plattformen verdrängen, sondern profitieren mit der Zeit von einem kumulativen Effekt.

Langsam KI lernen: Branchenperspektiven – Vier Organisationsformen der KI-Implementierung

Wenn eine Organisation kontinuierlich Skill ansammeln und jede neue Aufgabe als inkrementelle Skill-Aktualisierung nutzen kann, dann sind ihre KI-Fähigkeiten nicht gekauft, sondern gewachsen.

Acht: Branchenlinsen – Konkrete Erscheinungsformen der KI-Implementierung in vier Organisationstypen

Die folgenden vier Abschnitte sind keine Erzählung, sondern eine Zuordnung der abstrakten „sieben Schichten des Stack” auf konkrete Branchen, um zu zeigen, wo die jeweiligen Engpässe liegen.

Telekommunikation/Anbieter: Tarifänderungen, Geschäftskunden-Leitungsbereitstellung und übergreifende Störungsdiagnose erfordern das Durchqueren mehrerer Domänen – BSS, OSS, CRM und Abrechnung. Das größte Schmerzpunkts bei der Agenten-Implementierung ist die domänenübergreifende Abstimmung – wenn ein Agent im CRM einen Kundentarif ändert, muss er dies synchron an Abrechnung und OSS weitergeben, sonst stimmen die Abrechnungszyklen nicht überein. Die wertvollsten Schichten im Stack sind Schicht 5 Runtime & Tools (für die Anbindung multipler Domänenschnittstellen) und Schicht 7 Governance (für Finanz- und Abrechnungsprüfung).

Finanzsektor/Bankwesen: Risikosteuerung, Geldwäscheprävention, Kontenabstimmung und regulatorische Berichterstattung erfordern sämtlich Erklärbarkeit, Nachvollziehbarkeit und Auditierbarkeit. Ein Anti-Geldwäsche-Agent muss jede einzelne „Genehmigung” oder „Blockierung” damit begründen können, auf welcher Regel, welchem Transaktionsverlauf und welchen Kundendaten sie basiert. Auf dem Stack ist die wertvollste Ebene die 6. Schicht Verification (erklärbare Evidenzkette) und die 7. Schicht Governance (Algorithmusregistrierung + grenzüberschreitende Datenflusskontrolle) – diese beiden Schichten stellen unter dem hiesigen Finanzaufsichtsrahmen verbindliche Inbetriebnahmevoraussetzungen dar, keine „Bonuspunkte”.

Fertigung/Produktion: MES-, ERP-, QMS- und SRM-Systeme sind seit Langem voneinander isoliert, und eine domänenübergreifende Entscheidung (beispielsweise „Soll bei unzureichender Produktionskapazität zusätzlich Material beschafft werden?”) erfordert Hin- und Hergreifen zwischen vier Systemen. Die praktische Erscheinungsform von Agenten in der Fertigung ist eine systemübergreifende Orchestrierungsschicht, nicht ein Ersatz für Einzelsysteme. Sie liest gleichzeitig Materialdaten aus dem ERP, Fehlerraten aus dem QMS, Kapazitätsauslastung aus dem MES und Lieferantenleistung aus dem SRM, um eine Gesamteinschätzung zu treffen. Auf dem Stack sind die wertvollsten Ebenen die 5. Schicht Runtime (Enterprise-API-Gateway) und die 3. Schicht Context (akkumuliertes Prozess-Know-how, historische Störungen und Shopfloor-Erfahrungen).

E-Commerce: Domänenübergreifende Abläufe bei großen Verkaufsaktionen – Bestellung, Bezahlung, Bestandsverwaltung, Logistik und Kundenservice – erfordern intensive Lasttests, konsistente Lagerbestandsführung, Betrugsprävention sowie plattformübergreifende Abstimmung. Die ersten Agenten-Anwendungen im E-Commerce haben sich in der kreativen Vermarktung (Ersetzen von Produktbildern, Hintergrundwechsel, Erstellung mehrsprachiger Inhalte) und als Kundenservice-Assistenz etabliert. Den größten Wert auf dem Stack bieten die vierte Ebene – Skills (Compliance- und Prüfprozesse für SKU und Kanäle jeder Plattform) – und die sechste Ebene – Verification (automatisierte Bewertung, ob Inhalte den Plattformrichtlinien entsprechen).

Gemeinsamkeiten der vier Organisationstypen: Je weiter unten auf dem Stack, desto sinnvoller ist das Teilen; je weiter oben, desto wertvoller der Eigenbau. Basisfunktionen wie Runtime, Model Router und Tool Gateway profitieren von gemeinschaftlicher Entwicklung oder dem Einsatz bewährter Open-Source-Stacks – das ist wirtschaftlich effizienter. Skills, Context und Governance müssen jedoch selbst aufgebaut werden, da sie eng mit Geschäftsprozessen, Compliance-Anforderungen und organisationsspezifischen Ressourcen verknüpft sind.

Neun – Das Endprodukt kann völlig unterschiedlich aussehen, doch der Unterbau teilt ein gemeinsames Betriebssystem

Ein Coding-Agent und ein Video-Agent unterscheiden sich grundlegend in Benutzeroberfläche, Zielgruppe und Geschäftsmodell.

Doch beide benötigen im Kern: Context, Task, Skills, Tools, Runtime, Verification, Memory und Governance – und münden letztlich in messbaren Geschäftsergebnissen.

慢慢学 AI

企业知识 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 平台”——后者是过去两年许多团队踩过的坑：试图一次性覆盖所有场景，结果每个场景都无法达到可用深度。

慢慢学AI——通向企业级AI落地的实践指南

Ein soliderer Ansatz beginnt damit, zunächst den Wert an konkreten Aufgaben zu verifizieren und dann die sich wiederholenden Basisfunktionalitäten herauszuarbeiten. Die zugrundeliegende Erkenntnis: Eine通用层 (universelle Basisschicht) lässt sich nur aus konkreten Anwendungsszenarien entwickeln, nicht aus Architekturdiagrammen. Wenn man von Anfang an ein Runtime-System konzipiert, das „alle Szenarien unterstützen” soll, bedeutet dies in der Regel, dass für kein einzelnes Szenario eine wirklich durchdachte Lösung geschaffen wird.

Drei Fragen zur Selbstüberprüfung (zur Kontrolle nach dem Verfassen):

Wurde die abstrakte Runtime-Schicht tatsächlich bereits in mindestens zwei konkreten Szenarien auf ihre Allgemeingültigkeit hin validiert?
Folgt jedes Schichtdesign einem konkreten Geschäftsproblem, das in der Praxis tatsächlich aufgetreten ist?
Wenn heute das Budget um die Hälfte gekürzt würde – welche Schichten würden wir beibehalten? Falls die Antwort „Kontext und Skills” lautet, ist die Richtung richtig; falls es „Runtime und Gateway” sind, muss möglicherweise neu konzipiert werden.

Dieser Eindruck von der Cloud Compute Conference (云栖大会) bestärkt eine langfristige Einschätzung: Über den Modellen entsteht eine neue Systemschicht, die nicht专属某一款产品 (an ein einzelnes Produkt gebunden) ist, sondern sich zunehmend als das Betriebssystem der Agent-Ära herausbildet. Wer diese OS-Schicht zuerst stabilisiert, wird mit größerer Wahrscheinlichkeit von den Vorteilen der nächsten Produktiteration profitieren.

Implikationen für Entscheidungsträger

Wenn Sie als Enterprise-KI-Verantwortlicher (CDO/CIO/CTO) in einem Unternehmen mit einem Jahresumsatz von über 500 Millionen Yuan tätig sind, gibt es drei Maßnahmen, die Sie jetzt einleiten können:

Erstellen Sie eine Momentaufnahme Ihres aktuellen siebenstufigen Agent Stack – Kaufen Sie nicht voreilig neue Produkte. Verschaffen Sie sich zuerst einen Überblick, welche Ebene aktuell noch ein Weißfeld, ein Fremdprodukt oder eine Baustelle ist. Diese Darstellung allein wird die eigentlichen Engpässe offenlegen.
Wählen Sie ein Szenario mit hoher Kapitalrendite und durchlaufen Sie damit einen vollständigen vertikalen Kreislauf – Bauen Sie nicht zuerst eine Runtime auf. Ob Coding Agent, Kundenservice-Assistenz oder F&E-Assistent – Ihnen freigestellt. Durchlaufen Sie die vier Ebenen Context, Task, Skill und Verification komplett, bevor Sie über den „Plattformaufbau” sprechen.
Setzen Sie Governance auf Engineering-Ebene um, nicht nur auf Compliance-Ebene – Berechtigungen, Audit-Trails, Erklärbarkeit, Fehlerattribution und Management von Drittanbieter-Abhängigkeiten müssen von Beginn an gemeinsam mit den Business Agents gestaltet werden, anstatt nachträglich ergänzt zu werden.

Häufig gestellte Fragen

F1: Wo liegt der Unterschied zwischen diesem siebenstufigen Stack und den Multi-Agent-Orchestrierungs-Frameworks von Gartner oder IDC?

Gartner und IDC fokussieren sich auf die bereichsübergreifende Koordination und Steuerung mehrerer Agenten auf Organisationsebene. Der siebenstufige Stack hier beschreibt die interne technische Architektur eines einzelnen Agenten. Eine Organisation kann durchaus beide Betrachtungsebenen gleichzeitig adressieren – der einzelne Agent durchläuft die sieben Ebenen, während die Interaktion zwischen mehreren Agenten über Orchestrierung gesteuert wird. Der Stack ist mikro, Orchestrierung ist makro.

Q2: Warum bildet die Modellebene keine eigenständige Schicht?

Weil Modelle in einem Agent-System quer durch alle Ebenen verlaufende Ressourcen sind – keine exklusive Schicht. Der Model Router behandelt verschiedene Modelle wie unterschiedliche Rechenkapazitäten, die调度 werden, und ordnet sie auf dieselbe Stufe wie Shell und Browser in der Runtime – als „Werkzeuge”. Modelle sind natürlich entscheidend, aber sie können nicht die gesamte Komplexität eines Agents für sich beanspruchen.

Q3: Sollten kleine Teams diese Schicht überspringen und direkt auf End-to-End-Produkte wie ChatGPT oder Claude setzen?

Ja. Für Teams mit einem Jahresumsatz unter 100 Millionen CNY und geringer Organisationskomplexität ist es kosteneffizienter, fertige Agent-Produkte wie Browser Use, Manus oder Alibaba Cloud Bailian Agent zu nutzen. Die sieben Schichten, die in diesem Artikel diskutiert werden, gehen von der Frage aus: „Sollte eine Organisation mit einem Jahresumsatz von über 5 Milliarden CNY ihre eigene Agent-Plattform aufbauen?” – Für kleine Teams wäre der Aufbau einer Plattform eine umgekehrte Optimierung.

Reverse-Selbstcheck (für Sie, und für mich selbst)

Wenn Sie bei den folgenden drei Aussagen innerlich nicken, könnte es sein, dass Sie sich von der Erzählung mitreißen lassen, anstatt mit Beweisen zu arbeiten:

So lernt man langsam KI: Ein Leitfaden für Entscheidungsträger

IAIUSE Research Advisory Blog – Für CIOs und Entscheidungsträger in der Telekommunikation, Finanzdienstleistung, Fertigung und im E-Commerce.

Häufige Missverständnisse bei KI-Agenten

1. „Wenn das Modell stark genug ist, werden die Agents von selbst funktionieren.”
(Das Modell ist eine notwendige, aber keine hinreichende Bedingung. Die oberen sechs Schichten entscheiden darüber, ob es in die Produktion kommt.)

2. „Wir brauchen eine Allzweck-Agenten-Plattform.”
(Die Kosten für diese Idee überschreiten wahrscheinlich den Geschäftswert, den sie in 6 Monaten generieren kann.)

3. „Mit dem Skill-Aufbau kann man warten, bis das Modell stabil ist.”
(Skills sind Organisationsvermögen – jeden Tag, den man sie nicht aufbaut, verzögert man den Zinseszinseffekt.)

Wenn Sie den ersten drei Aussagen nicht zustimmen, lesen Sie weiter.

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

„One workbench. Four entries. One foundation.” – Qoder-Standbanner und Blog, vor Ort auf der Cloud Computing Conference 2026 (云栖大会) sowie im Beitrag „Introducing Qoder 1.0” vom 31.08.2026 auf der Alibaba Cloud Community. Evidenzklasse: Herstelleraussage (Alibaba-Standpunkt).
QwenWork Legal Document Fill Out: Sandbox-Container + virtueller Desktop + Tool-Aufruf – Alibaba-Cloud-QwenWork-Live-Demo, Beitrag auf Alibaba Cloud Community vom 25.09.2026. Evidenzklasse: Herstelleraussage (Alibaba-Standpunkt).
QoderWake als „Digitaler Mitarbeiter”-Produkt, veröffentlicht von Alibaba am 30.04.2026 – Baidu-Enzyklopädie-Eintrag zu Qoder + Alibaba-Offiziell. Evidenzklasse: Herstelleraussage (Alibaba-Standpunkt).
OWASP 2026 威胁清单将 Prompt Injection 置于首位 – Überblick „State of Browser Use, Mai 2026” (Michael Livs Blog). Evidenzklasse: Drittparteien-Synthese (OWASP-Position, Branchenkonsens).
Requesty: Gestaffeltes Routing mit 70/20/10-Verteilung kann Kosten um 60–80 % senken – Requesty Unternehmensblog, 2026. Evidenzklasse: Herstelleraussage (Position des Modell-Routing-Anbieters, Zahlen tendenziell optimistisch, nur als Richtwert zu verstehen).
Microsoft Agent Governance Toolkit (AGT), am 02.04.2026 als Open Source (MIT-Lizenz) veröffentlicht – Bericht auf niteagent.com. Evidenzklasse: Drittparteien-Synthese (Microsoft-Position, jedoch Open-Source-Projekt mit überprüfbaren Zahlen).
Anthropic Skills Protokoll: Veröffentlichung am 16. Oktober 2025, Open-Source-Umstellung als offener Standard am 18. Dezember 2025 — Synthese aus Anthropic Engineering Blog + Substack + Medium LM Po. Evidenzklasse: Herstellerangabe + Drittanbieter-Synthese (Anthropic-Standpunkt).
IDC-Prognose: 40 % der Fertigungsunternehmen werden 2026 KI-gestützte Produktionsplanung einführen — Groovy Web Review 2026, unter Berufung auf IDC-Bericht. Evidenzklasse: Drittanbieter-Synthese (IDC-Standpunkt, Richtungsangabe als Referenz).
Stripe „Minions”: Wöchentlich 1.300+ PR-Merges, 0 Personen schreiben Code, vollständig manuelles Review — Stripe Engineering-Team, Steve Kaliski, in der Show „How I AI” am 25. März 2026 + Berichterstattung von ByteMonk am 14. Februar 2026. Evidenzklasse: Herstellerangabe (Stripe-Standpunkt, Zahlen als Referenz, Kontext ist Stripe-interne Engineering-Abläufe, nicht auf Branchendurchschnitte übertragbar).
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 年 7 月中国 AI 法规月度简报。证据层级：第三方综合（法律机构立场，法规文件可查）。
TinyFish: 47 Mio. USD Finanzierung, Kunden u. a. Google, DoorDash und Amazon, Browser-Kaltstart <250 ms — SwitchTools 2026 Review. Evidenzgrad: Dritte Stelle, aggregiert (Standpunkt eines Produktbewertungsportals; Zahlenangaben auf der offiziellen TinyFish-Website verifizieren).

Falls Sie gerade evaluieren, wie Sie eine unternehmensinterne Agent-Plattform aufbauen sollten, welche Fähigkeiten Sie selbst entwickeln, zukaufen oder gemeinsam nutzen sollten und welche Agent-Runtime den höchsten Wiederverwendungswert bietet, sprechen Sie uns gerne an. Wir bieten spezialisierte Beratung für die unternehmensweite KI-Transformation — von der Agent-Architektur und Runtime-Design bis hin zur Skill-Dokumentation, damit aus Ihren „punktuellen Agents” eine „organisationsweite Agent-Plattform” wird.

Unternehmensschulung

Zielgruppe: Führungskräfte und Schlüsselkräfte aus der Linie – ein dreitägiger Grundlagenkurs, 90.000 ¥ pro Veranstaltung. Wir zerlegen das 7‑schichtige Agent‑Stack, die Governance‑Perspektive aus Engineering‑Sicht und die Methodik der Skill‑Verankerung und bringen sie direkt in Ihr Team.

Spezialisierte Beratung

90‑minütige Architektur‑Diagnose ab 3.000 ¥ – eine unabhängige Bewertung, die Ihnen einen Schnappschuss der aktuellen sieben Schichten Ihrer Organisation liefert, Lücken identifiziert und eine Einschätzung gibt, ob Make‑vs‑Buy sinnvoll ist. Tiefe Begleitung wird projektbasiert angeboten.

Führungskräfte‑Keynotes & Branchenvorträge

Öffentliche Konferenzen, geschlossene Runden oder Forumsbeiträge – kontaktieren Sie uns für eine maßgeschneiderte Agenda.

Kontakt: [email protected]

Weiterführende Lektüre: „Das 7‑Schritte‑Framework für KI‑Transformation” – eine systematische Darstellung des vollständigen Wegs zur unternehmensweiten KI‑Implementierung.

Lokalisierungshinweise (mehrsprachige Übersetzung, IAIUSE-Strategie · 2026-08-09-Vereinbarung)

Bei der Übersetzung in 19 Sprachen werden die folgenden Inhalte für den Ziellinienmarkt lokalisiert, Struktur und visuelle Gestaltung bleiben unverändert:

中文稿内容	英文版	日文版	德文版	阿拉伯版
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

| Browser-Agent |

| Domänenkompetenz / Programmierkompetenz / SEO‑Recherchekompetenz / E‑Commerce‑Kreativkompetenz / Operationskompetenz | Domänenkompetenz / Programmierkompetenz / SEO‑Recherchekompetenz / E‑Commerce‑Kreativkompetenz / Operationskompetenz | Domänenkompetenz / Programmierkompetenz / SEO‑Recherchekompetenz / E‑Commerce‑Kreativkompetenz / Operationskompetenz | Domänenkompetenz / Programmierkompetenz / SEO‑Recherchekompetenz / E‑Commerce‑Kreativkompetenz / Operationskompetenz | Domänenkompetenz / Programmierkompetenz / SEO‑Recherchekompetenz / E‑Commerce‑Kreativkompetenz / Operationskompetenz |

Über diese Serie

„Cloud Village Insights” ist die praxisnahe Branchenserie von IAIUSE, die vom Cloud Village Summit 2026 ausgeht und mit Forscherblick die echten Veränderungen in der KI-Industrie seziert – keine Trends jagend, sondern nur die Richtungen und die Stärke der Belege betrachtend.

Die Serie umfasst Themen wie die Systemschicht über Modellen, Agent-Implementierung, Context-Assets, Unternehmens-KI-Organisationsdesign und die Verlagerung der KI-Produktwettbewerbseinheiten, insgesamt etwa 10 Beiträge.

Rund acht Jahre Erfahrung in der Unternehmensberatung und Geschäftsanalyse bringe ich mit. Während meiner Tätigkeit bei IBM war ich in Projekten für Telekommunikation, Finanzwesen, Versicherungen und die Fertigungsindustrie eingebunden. Anschließend war ich an der vordersten Front in der Entwicklung von Betreiberprodukten, Internetprodukten und KI‑Anwendungen tätig und verantwortete Anforderungsanalysen, Produktdesign sowie unternehmensübergreifende Umsetzung. Dieses Konto wird von einem kleinen Team getragen – mir und ein bis zwei langjährigen Mitarbeitern, die jeweils für die Forschung zu KI‑Programmierwerkzeugen, die Analyse von Governance‑Fällen und Coaching‑Gespräche zuständig sind. Die meisten Projekte, bei denen wir Unternehmen begleitet haben, wurden von uns gemeinsam umgesetzt.

Unsere Forschungssammlung umfasst mittlerweile über 200 Beiträge. Die Einschätzungen in dieser Serie basieren auf meinen Vor‑Ort‑Beobachtungen und einer branchenübergreifenden Validierung. Sie geben eine klare Autorenposition wieder und vertreten keine Meinung eines Anbieters.