全权能栈——五项“AI优先”架构理念，将革新您软件开发之形

数十年间，"全栈开发者"之称号，象征技艺之巅峰。此辈能于前端、后端、数据库及用户体验间，游刃有余，驾驭自如。然今，根本之变，已然发生。

A 语言模型之升，为技术之堆添一"认知之层"。融智于器，已非可有可无之选，乃结构之必也，犹若数据库之不可或缺。其喻直而力：五至七年，无本智之系统，其废也，犹无响应之网页。

是时，新范式出焉：曰"全能代理栈"。此乃架构之模，生而具灵，初构即谋思虑，行止有度。今当探其五义之尤彰者，此新模正易软件之制也。

智械非插件，乃新核之枢也。

至深之变，在于文脉与构架。旧式之制，AI常为后加之器，以应专项之能。新法以AI为先，则AI为系统运作之基——遂成枢要。

此新构架，名曰"全智能栈"(Full Agentic Stack)，其义可释如下：

全能栈乃一完整软件生态，由认知层、自主层与反应层构成，诸层协舞，以解、决、行实时之变。

为匠者，此定义化为一组熟稔之工程范式，相得益彰：事驱动架构（EDA）、如CQRS及事件溯源之范式，并辅以由认知代理协奏而成之基础，此代理与反应式、多模态之数据层相交互。

忽此知性之层，犹若无库之建新用，非其本也。无库之系，不可为用；无知性之系，不可争胜。盖其无学之能，无适之巧，无复繁务之协，此乃旧制之理，固不能及也。

尔次之API乃自然语言

依传统模式，与系统交互乃直通HTTP请求，须用户或他系统识API之结构。全能代理栈则逆此理。交互始于自然语言，继而译为"意向"之结构.

模型请求
依古之HTTP径直至一端点（GET /api/orders?client=...）
全能栈自然言 → 结构意

今举商贾之实例。一客书曰：

“吾欲周知约翰客近周所为之货。”

吾有项目名曰"CogGate"，此项目通过大语言模型，将此句解读，并转化为系统所能理解的JSON结构化指令。

{
"意旨": "依客列单"
"参数": {
"客户": "João",
"期间": "本周"
}
}

其主效在于交互之直觉大增。系统应用户之需，用户无须谙悉SQL，亦不必识API之名，更不需知数据库之内部结构。其繁复，乃为智能之层所化。

O CogGate 乃一项目，能化任何旧有系统为认知MCP服务器。其能将自然语言提示转为执行既有功能，唯需添一提示以辨功能之用，并定其所需之架构，于v0.1.0版本中，吾以zod为之。是故，但运行openintent.forger.ts，即可读取汝之coggate.json，此即其事也。

{
  "$schema": "https://neurohive.dev/schemas/cognitivegateway-config.schema.json",
  "version": "1.0.0",
  "mode": "cognitive",
  "description": "Configuração base do Cognitive Gateway para execução de intents via OIP.",
  "oip": {
    "file": "openintent.json",
    "autoRegenerate": true
  },
  "llm": {
    "provider": "openai",
    "model": "gpt-4o-mini",
    "apiKey": "sk-proj-..."
  },
  "controllers": [
    "src/modules/*/controllers/**/*.ts"
  ],
  "gateway": {
    "promptRoute": "/prompt",
    "port": 8080,
    "logLevel": "info",
    "language": "pt-BR"
  },
  "execution": {
    "sandbox": false,
    "maxTokens": 512,
    "timeout": 10000
  }
}

Nessa v0.1.0 eu fiz em cima da arquitetura modularizada onde cada action de um Controler 乃一模块化、原子化之文件，须知其控驭含诸函数之对象，此函数乃由路由所执行。于v0.2.0版本，吾将施此机制于类文件及控制器文件，其于同一文件内含有多函数者，吾将采其常见之例，俾开发者无需更易一码，惟增提示与架构耳。

故 openintent.forger.ts 将生成openintent.json 乃自然语言意图之 OpenAPI，其联接各功能之提示，及其模式，俾 LLM 得辨何功能应用，据输入提示而定。

LLM 亦不执行一事，惟言何功能应行，及何数据应供是提示。

吾惟以此示 LLM：

const list = Object.entries(intents)
      .map(([id, v]) => `${id}: ${v.prompt}`)
      .join("\n");

//...

{ role: "system", content: "Classifique o prompt abaixo em uma das intenções listadas." },
{ role: "user", content: `${list}\n\nPrompt: ${prompt}` }

中list所含之文，乃"[函数名]:身份提示"之语。

欲使大语言模型依此提示，唯应回其Intent（函数名）。此乃openintent.json中例之貌：

 "intents": {
    "update": {
      "prompt": "Use esta intenção quando o usuário quiser **atualizar dados existentes**.\n\nExtraia o identificador (nome ou id) e os campos a atualizar.\nRetorne **somente JSON** no formato:\n{\n  \"identifier\": string | number,\n  \"fields\": {\n    \"name\"?: string,\n    \"email\"?: string,\n    \"phone\"?: string,\n    \"role\"?: string\n  }\n}",
      "examples": [],
      "behavior": {
        "controller": "modules.user.controllers.update",
        "operationId": "update"
      },
      "context": {
        "domain": "users",
        "language": "pt-BR"
      }
    },

察之，秘在于提示，唯其上，开发者须明示所求之架构，非必送JSON、架构、物之属。

此乃User/Controller/update.ts之文。

import { z } from "zod";
import { UserService } from "../services/index.js";

/**
 * @intent update
 * @example Mude o email da Maria para teste@teste.com
 * @context domain:users, language:pt-BR
 */
export const prompt = `Use esta intenção quando o usuário quiser **atualizar dados existentes**.

Extraia o identificador (nome ou id) e os campos a atualizar.
Retorne **somente JSON** no formato:
{
  "identifier": string | number,
  "fields": {
    "name"?: string,
    "email"?: string,
    "phone"?: string,
    "role"?: string
  }
}
`;

export const schema = z.object({
  identifier: z.union([z.string(), z.number()]),
  fields: z.object({
    name: z.string().optional(),
    email: z.string().email().optional(),
    phone: z.string().optional(),
    role: z.enum(["admin", "user", "guest"]).optional()
  })
});

export async function update(req, reply) {
  try {
    const { identifier, fields } = req.body;
    const service = new UserService();
    const updated = await service.update(identifier, fields);
    reply.send({ success: true, data: updated });
  } catch (error) {
    reply.status(400).send({ success: false, error: error.message });
  }
}

此架构当为典范，盖吾欲弘传此原子模块之制，使尔等制函数，若尔悟之，吾可为之：

//actions/controller.update.ts

盖因执行于路由之功能，当无业务规则，唯应验契约/架构，俾领域层可用之。吾所知至简之结构乃：

路由（输入/输出之关口）->控制器（数据之验）-> 服务（业务规则执行）—> 仓库（数据持久化）

君以为，无复增责于单层，事岂更简乎？

故，诸路之务，当皆通约，尔惟用一工坊制路，但纳实体之名与行名于是途。

app.post("/users", RoutesActionsFactory.forge("User", "create")

无他，盖汝已有此架构于数据平面/src/entities/user/schema.json察之，文件之名，当不含实体之名，惟其本也，盖其已存于实体之文件夹中，如是则助生成动态之码，例若JSON架构：

{
  "$schema": "https://json-schema.org",
  "title": "User",
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "username": {
      "type": "string"
    },
    "cpf": { 
      "type": "string", 
      "pattern": "^\\d{3}\\.\\d{3}\\.\\d{3}-\\d{2}$" 
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "phone": {
      "type": "string"
    },
    "password": {
      "type": "string"
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    },
    "updatedAt": {
      "type": "string",
      "format": "date-time"
    },
    "deletedAt": {
      "type": [
        "string",
        "null"
      ],,
    "default": null
    "format": "date-time"
    }
  },
  "required": [
    "name",
    "username",
    "email",
    "cpf",
    "password",
  ]
}

汝当自问：

验证身份证之功能安在？

吾答曰：

以SemanticTypes观之，万物皆备一validate，此乃常法。

然今论常例：汝当立一文书。/src/entities/user/cpf.validate.ts

何時生成《諸子》之範式與其ORM/ODM之範式，凡有屬檔名含「.validate.ts」之屬性，皆可簡以require/import，無需於每層使用處重寫此函數。吾未知君意，然最少之驗證有二：路由與儲存庫。吾之架構中，《語義類型》之函數「驗證」遇一值即自動執行，開發者無需寫一字。若值途經中間被改，則終至流程末尾方知，引入此函數毫無損失，僅需喚之。

// src/routes/user.routes.ts
import { RoutesActionsFactory } from "../shared/factories/RoutesActionsFactory.js";

export async function userRoutes(app: any) {
// 动态生成洁净之路由，以Factory为用
app.post("/users", RoutesActionsFactory.forge("User", "create"));
app置"/users"，RoutesActionsFactory造("User"，"updateBy")
app删"/users"，RoutesActionsFactory造("User"，"deleteBy")
app取"/users"，RoutesActionsFactory造("User"，"findAll")
app取"/users/:identifier"，RoutesActionsFactory造("User"，"findBy")
}

思辨之系非徒行脚本者

常制之构，恃固性之控，循既定之序。若A生，则行B。然于全能之栈，此制易为“诸使”之协舞。每使司一域（价、诉、宣），互议相协，以成繁务，遂启“自生之态”。

思此高阶之境：一管理者请于系统曰

"增诸商品之折，其于近四十八时内，所受之诉言逾十则也。"

非惟一脚本，乃次第之变与协动而生焉：

投诉之使（ComplaintAgent）察商品之诉率甚高，乃布一"高诉率"之变（HighComplaintRate(product_id)）。
O 定價之代理者，啟此事件，察他因（若銷售之趨勢），遂決施新折。
其決記之，啟營銷之代理者，以新編網上目錄，或訊諸客。

无中枢者统御其步。终局之果，生于专司之剂相与交感，若"自适之舞"，随境迁化，赖以 RabbitMQ、NATS、Kafka 诸强健之事件总线为之赋能。

开发者由编程者蜕为认知流之舞者。

是此新架构之需，须为开发者立一新名。其变也，自“全栈开发者”而转“全能开发者”。

其一主司前后端之层，其二主司"认知之流"。其任之要易矣。非复惟书代码以施固定之能，乃须谋制、训习、理智能体相与之际。其注移自代码之版，若吾所识之语义版（SemVer），转至行为之版（"Behavioral Versioning"），务使智能体之交相演进而有度可循。

O futuro é declarativo: sistemas que se autocompõem

Full Agentic Stack之终局，指范式之变，由"如何"转"为何"。不复编程系统须循之步履（如何），但由开发者宣示所期之果（为何），使自主之能者，于运行时自组微服务。

此乃于声明式文件中描述一整系统之可能，如 .tyflow.yaml。譬如：

代理人：

名：客事：[客成，客新] 存：postgres
名：訂單儲存：MongoDB 消費：[客戶創建] 生產：[訂單已置]
名：Analytics 存储：weaviate 监听：[OrderPlaced]

Ao executar tyflow run, o sistema cria filas, APIs, eventos e dashboards automaticamente — sem código manual. Isso aponta para um futuro de "engenharia sem código" — não no sentido de simplicidade, mas de alta abstração, onde a arquitetura se torna auto-adaptativa, reconfigurando fluxos com base no contexto. __JHSNS_SEG_e1ef8c7a_105__行tyflow run，系统自创队列、API、事件及仪表盘，无需手写代码。此乃“无码工程”之未来所向——非指简易，实乃高阶抽象，使架构能自适，依情境重构流变。

O "全能栈"非仅新工之集；乃软件发展之逻辑演进也。其认智能非复附属，实为根本且结构之要件。犹云与响应式设计已成不可或缺之范，原生智能当为现代软件之次柱。

吾辈正入一新时代，其终极之旨骤变。盖未来之发展，非惟编程智能之系统，亦乃系统自编程之系统也。

推薦訂閱源

DEV Community