构建能推理——也能运行的系统。

AI 是一个系统架构问题

当 AI 能够与真实数据、真实应用、真实基础设施和真实约束协同工作时，它才具有价值。模型只是其中一个组件。困难的部分在于围绕它设计一切，使整个系统能够可靠地运行。

我的工作聚焦于这一架构：模型如何访问知识、检索证据、使用工具、与软件交互、交换数据，并成为能够真正在生产环境中运行的系统的一部分。

这意味着要跨 AI 架构、应用逻辑、API、数据库、全栈平台、基础设施、部署和运维开展工作，而不是将 AI 视为一个孤立的功能。

当前技术重点

我当前的工作集中在模型能力与可靠系统行为之间的层面：决定模型何时可以使用自身知识，何时必须检索外部信息，什么证据是充分的，智能体应如何执行操作，以及必须在何处强制执行系统边界。

• 检索增强生成与检索触发
• 智能体系统、工具使用与执行循环
• 上下文边界、证据与答案可靠性
• 模型路由与能力感知架构
• 私有、本地与自托管 AI 基础设施
• 将 AI 集成到真实的应用与数据工作流中

AI 系统架构

现代 AI 应用并非仅由语言模型构建而成。可靠的系统需要对知识、检索、上下文、工具、应用状态、验证、模型选择和故障处理做出决策。

• RAG 与外部知识集成
• 检索决策与证据选择
• AI 智能体与基于工具的工作流
• 本地与远程模型架构
• 模型与能力路由
• 上下文设计与上下文边界管理
• 结构化输出与 API 集成
• 验证、可观测性与故障处理

因此，核心架构问题不仅仅是使用哪个模型。而是模型知道什么、不知道什么、必须检索什么、可以使用哪些工具、什么证据是充分的，以及系统何时必须停止信任生成的答案。

平台架构

AI 是更大软件系统中的一个层面。我围绕清晰的应用边界、可复用服务、结构化数据模型和面向生产的架构来设计平台，而不是孤立的功能。

• 云原生与自托管架构
• 多租户与多实例平台
• 后端服务与 API 架构
• PostgreSQL 与应用数据建模
• 身份验证、授权与基于角色的访问控制
• 多语言与国际化系统
• 无头内容与结构化发布平台
• 集成到现有应用逻辑中的 AI 服务

全栈系统工程

架构在能够经受实现考验时才最为重要。我跨前端、后端、数据和基础设施开展工作，使架构决策从用户界面一直到底层数据库、运行时和部署层都保持一致。

典型的系统结合了 Nuxt 和 Vue 前端、Node.js 和 TypeScript 服务、PostgreSQL 和 Prisma 数据层、在技术适配性更佳时使用的 Python，以及基于 Linux 的生产基础设施。

生产工程

原型用于验证想法。生产系统则必须经受部署、真实数据、需求变化、用户行为、流量、升级、故障以及持续开发的考验。

• Linux 服务器环境
• NGINX 与应用路由
• 应用部署与运行时运维
• 数据库迁移与数据生命周期
• 构建与发布工作流
• 日志、诊断与技术监控
• 性能、可爬取性与交付约束
• 本地与托管 AI 运行时的集成

实践中构建的系统

这里描述的架构并非理论构想。它是在我设计、构建、运维并持续扩展的系统中逐步发展而来的。

Aaasaasa AI 客户端

一款基于 Electron 和 TypeScript 构建的桌面 AI 应用，支持本地与远程模型、提供商抽象、安全的应用边界，并与外部 AI 运行时集成。

企业级 Aaasaasa

一个面向企业的平台架构，融合了应用服务、结构化数据、基于角色的访问控制、多语言内容、AI 能力以及模块化业务功能。

stajic.de 平台

一个用于结构化发布、多语言交付、AI 辅助工作流、技术研究以及围绕搜索、检索和 AI 可读知识的实验的生产平台。

独立生产平台

loving.rocks、figure.rocks 及相关系统将相同的工程方法延伸到独立的生产环境中，这些环境拥有各自的受众、内容模型、多语言结构、搜索需求和运营约束。

技术研究与写作

我当前工作的一个重要部分，是考察语言模型能力与可靠应用行为之间的边界。目标是将复杂的 AI 架构转化为可解释、可测试、可质疑并可实施的概念。

• RAG 如何将模型连接到外部知识
• LLM 从哪里获取信息，以及检索从何处开始
• AI 系统何时应停止依赖模型知识
• 证据应如何被选择和验证
• 为什么更大的上下文窗口并不自动产生更好的答案
• 智能体循环与托管式智能体基础设施有何不同
• 私有 AI 架构如何改变基础设施决策
• 答案可靠性在检索与生成之间的何处失效

这些主题构成了一个相互关联的技术知识库，而不是一组孤立的文章。每一篇都针对现代 AI 系统内部的不同边界。

一个系统，而非功能的集合

前端、后端、AI、数据和基础设施常常被作为彼此独立的学科来讨论。但在生产环境中，它们持续地相互影响。

检索决策改变数据架构。数据架构影响API。API影响应用状态。应用状态影响智能体行为。基础设施限制模型选择。搜索架构影响人和机器发现信息的方式。

因此，我的方法是面向系统的：在优化单个组件之前，先理解完整的链路。

技术基础

• TypeScript 和 JavaScript
• Nuxt 和 Vue
• Node.js 和 Nitro
• Python
• PostgreSQL 和 Prisma
• REST 和应用 API
• Electron
• Linux 和 NGINX
• Docker 和基于服务的部署
• OpenAI API 和智能体工具
• 包括 Ollama 在内的本地 LLM 运行时
• 结构化内容和 EditorJS

架构也必须可交付

技术架构存在于产品、项目、预算、依赖关系和截止日期之中。因此，我的工作将工程与结构化交付结合起来，而不是将技术决策与实施责任分开。

二十多年的实际 IT 工作经验，辅以正式的项目和交付方法，包括 IPMA 和 Professional Scrum Master 认证。这些方法支持工程工作；它们不会取代工程工作。

构建真正能运行的东西

目标不是把 AI 附加到所有东西上。而是识别 AI 在何处提供真正的系统能力，围绕它设计架构，并足够扎实地构建周边软件，使这种能力变得有用。

从检索和模型行为到 API、数据、界面和基础设施，重点始终如一：技术上连贯的系统，能够从架构走向生产。