面向企业的 AI 智能体：平台、组件、渠道

引言

AI 智能体不只是按脚本回答的聊天机器人。它们是能够理解上下文、连接您的数据库和文档、调用 API 并做出决策的智能系统。对业务而言，这意味着：更少的例行事务、更快的响应、更低的成本、更高的质量。

我们划分出四种类型的智能体，覆盖任何公司的关键需求：

类型	功能
支持智能体（FAQ）	根据知识库、规章制度、文档回答问题
顾问智能体（销售）	帮助选择商品、进行比较、下单、进行交叉销售
员工助手	办理休假、重置密码、查找命令、进行入职引导
数据分析师	将业务问题转化为 SQL，返回答案 + 图表

但在这些智能体中的每一个背后，都有一个共同的平台——正是它决定了智能体是否便捷、安全、可控。在本文档中，我们将剖析平台的业务组件和交付渠道。

平台的业务组件

1. 对话分析

没有分析，智能体就是一个黑箱。业务需要了解内部发生了什么。

分析能带来什么：

能力	对业务的价值
请求仪表盘	有多少对话、在哪些渠道、在什么时间。用于资源规划的负载峰值
按智能体细分	每个智能体的负载和活跃度
升级漏斗	智能体自行解决了多少对话，有多少转给了人工坐席
词汇主题	最常问的是什么——问题中的高频词，无需人工标注（无需嵌入）
对话搜索	对全部历史记录进行全文搜索——合规、事件复盘、培训
盲区	经常返回空结果或失败的工具：需要改进的地方
用户评分	对智能体回答的点赞/点踩——改进的信号

分析是选择性启用的：默认情况下不统计任何智能体，可全局启用或针对特定模板启用。

示例，它可能的样子（数字为假设）：

📊 2026 年 7 月仪表盘
├─ 对话总数：8 230
│  ├─ 智能体解决：5 760（70%）
│  ├─ 已升级：1 810（22%）
│  └─ 未解决（知识库中没有）：660（8%）⚠️
├─ 前 5 大主题：
│  1. 订单状态 — 2 140
│  2. 退货/残次品 — 1 520
│  3. 发往各地区 — 980
│  4. 商品比较 — 890
│  5. 保修 — 720
├─ 平均响应时间：1.2 秒
└─ 平均用户评分：4.7 / 5

2. 安全

AI 智能体处理公司数据——文档、客户数据库、财务信息。安全不是可选项，而是基石。

防护层级：

层级	包含内容
隔离	智能体不读取其他智能体的上下文，也不消耗其预算。记忆和状态按用户/会话限定作用域。一个实例——一个边界（不声明按客户的多租户）
访问控制	管理员令牌和 web 用户受模板列表限制（限定作用域的操作员）。管理员 API 故障关闭
个人数据保护	钩子 `guard` 查找 email、电话、银行卡、IBAN、护照、ИНН、СНИЛС、API 密钥、PEM；动作为 `redact`/`deny`/`rework`。`pseudonymize` 可逆地将值替换为令牌，并将其存储在本地加密 vault 中
操作审计	每个 HTTP 请求的访问日志和事件日志（工具调用、预算、错误、操作员决策）。令牌值不被记录
操作审批	敏感工具在核心层通过 human-in-the-loop 进行门控——智能体无法绕过审批，包括通过 prompt injection
密钥与加密	密钥仅在 `.env` 中，YAML 中只有变量名；服务器级 TLS；连接器的 OAuth 令牌加密（AES-256-GCM）
执行隔离	工具在沙箱中运行（文件系统和网络限制）。数据库访问通过 `sql_tool` 并带有可配置的 `readonly`（默认允许写入）；`shell_tool` 仅运行作者 CLI

示例：个人数据掩码如何工作

用户：我的护照 4512 345678，请检查订单
智能体（看到）：我的护照 [PASSPORT_MASKED]，请检查订单
日志中：       [PASSPORT_MASKED] — 原始数据不被
               保存，仅保存发现个人数据的事实

3. 知识库与数据

智能体的优劣完全取决于其知识的时效性。来源分为两种类型：检索档案和通过工具获取的实时数据。

智能体如何获取知识：

方式	如何工作	适用于哪些数据
搜索归档	网站由爬虫（`agent-os scrape`）遍历为全文归档（BM25）。钩子 `rag` 将相关片段注入上下文，`archive_tool` 在归档中搜索	规章制度、操作说明、FAQ、网站内容
按需文档	PDF、Word/Excel/PowerPoint 在请求时由工具读取（`pdf_tool`、`office_tool`）——无需预先索引	命令、条例、合同
实时数据（API）	`site_tool` 和 OAuth 连接器实时访问 REST-API；`sql_tool` —— 查询 PostgreSQL/MySQL；`duckdb_tool` —— 智能体自有的数据库	商品、价格、订单状态
RSS / JSON	`rss_tool` 和 `json_tool` 在订阅源和文件中搜索	新闻、数据导出

更新机制。 归档由爬虫重新构建——手动、脚本或按 cron 执行。没有文档（Confluence、Google Docs、1С）的自动索引，也没有知识库的版本管理。

4. 质量控制

智能体不应只是回答，而应回答得好。质量依靠可管理的机制来维持。

机制	作用
回答落地校验	钩子 `groundedness` 将回答中的陈述与归档及工具结果进行比对；`link_check` 检查引用
模式与格式	`schema_guard` 按 JSON Schema 校验回答和工具参数；`format_guard` 跟踪引用
循环中断	`loop_guard` 阻止工具调用陷入循环
用户评分	对回答点赞/点踩（`feedback`），为管理员提供统计
可观测性	按点位的钩子指标、计时、提供商熔断、Prometheus `/metrics`
基准测试	在场景集（`bench`）上运行智能体并保留结果历史
盲区分析	智能体最常无法应对的工具和问题（对话分析）

5. 集成层

智能体并非存在于真空之中——它接入公司的 IT 环境。

内置集成：

系统	提供的能力
Google	Drive、Sheets、Docs、Slides 和 Calendar（`google_tool`、`calendar_tool`）
Yandex	Yandex.Disk 和 Yandex.Calendar（`yandex_tool`）
数据库	通过 `sql_tool` 访问 PostgreSQL 和 MySQL；智能体自有的 DuckDB
文件存储	S3、WebDAV、FTP（`storage_tool`）
邮件	IMAP 接收和 SMTP 发送（`email`）
即时通讯	Telegram、VK、Yandex Messenger（频道和 sink）
任意 API	`site_tool`（REST、OAuth2、HMAC 签名）和 OAuth 连接器（`oauth_connect`/`connector_request`）
MCP 服务器	任何符合 Model Context Protocol 标准的工具（`mcp_tool`）

规划中： 1С/ERP、amoCRM/Bitrix24、Active Directory/LDAP、ClickHouse、Jira/Kaiten/Notion、支付网关（ЮKassa 等）、配送服务（СДЭК、ПЭК、Почта России）、WhatsApp Business API。目前尚无原生支持——其中一部分只能通过 site_tool 以任意 HTTP 方式实现。

交付渠道

智能体应当出现在用户所在之处。不是用户去找智能体，而是智能体去找用户。

1. 网站上的挂件

面向外部客户最显而易见的渠道。

特性	描述
位置	公司网站、在线商店、个人账户、政务服务门户
外观	右下角的浮动按钮「与 AI 聊天」。点击后弹出对话窗口
自定义	颜色、徽标、欢迎语、智能体头像
升级转接	如果智能体未能解决 → 转接人工客服（聊天、电话、工单）
上下文	智能体能看到用户所在的页面，并可在回答中加以利用
分析	每个会话都会被记录，流量来源已知

部署示例：

大学网站
├─ 首页 — 挂件提示：「我可以回答关于
│  招生、课程安排和校园生活的问题」
├─ 招生页面 — 挂件自动提示：
│  「想了解您所在院系的录取分数线吗？」
└─ 学生个人账户 — 挂件结合上下文：「需要开具
   在读证明吗？我来帮您办理」

2. Telegram 机器人

俄罗斯最流行的内部沟通与支持渠道。

特性	描述
位置	独立的机器人 @CompanyHelperBot 或嵌入企业聊天
面向对象	员工（HR、IT、文档）、客户（支持、订单）、合作伙伴
优势	无需安装——人人都有 Telegram。推送通知。熟悉的界面
文档	直接在聊天中发送 PDF、图片、表格
按钮	快捷操作：「我的工资单」、「订单状态」、「申请休假」

制造业场景（生产型企业）：

车间员工在智能手机上打开 Telegram → @CompanyHelperBot
→「申请调休」→ 一个按钮 → 完成。

无需：找电脑、登录 1С、记密码、
研究界面。

3. VK、Yandex Messenger、email 和 API

除挂件和 Telegram 外，智能体还可接入其他渠道：

渠道	特性
VK	通过 Long Poll 的社区机器人：消息、附件、快捷操作
Yandex Messenger	通过 `getUpdates` 的 Yandex 360 机器人——面向 Yandex 平台上的员工
Email	通过 IMAP 接收邮件并通过 SMTP 回复；`email_tool`——外发
HTTP API (SSE)	`POST /v1/chat/completions`——主要的程序接口和响应流式传输
Webhook	`POST /v1/inbound/:template`——外部系统启动代理并同步获取响应

渠道对比

渠道	应用场景	授权	Push
网站小部件	网站、在线商店、个人中心	网站会话	否
Telegram	外部客户和员工	单独（手机/令牌）	是
VK / Yandex Messenger	社区、企业内网	机器人/社区令牌	取决于平台
Email	外部通信、工单	IMAP 账户	否
HTTP API	嵌入自有产品	Bearer / 用户票据	否

补充： 观察者代理的工作结果会进入 sink——webhook、Telegram、VK、Yandex Messenger、email、另一个代理或存储（S3/WebDAV/FTP）。

架构：工作原理

flowchart TB
    subgraph channels["📱 渠道"]
        Widget["网站小部件"]
        Messengers["Telegram · VK · Yandex"]
        Api["HTTP API (SSE)"]
        Email["Email"]
    end

    subgraph triggers["⏰ 触发器——无需人工启动"]
        Cron["Cron"]
        Webhook["Webhook"]
        Monitor["Monitor（RSS 等）"]
    end

    Host["🌐 主机——HTTP 服务器<br/>认证 · 管理 UI"]

    subgraph kernel["🧠 内核——代理的操作系统"]
        direction TB
        Sched["调度器<br/>并发与队列"]
        Processes["进程表<br/>代理 = 进程（PID、状态）"]
        Ctx["上下文（类似 RAM）<br/>换出与压缩"]
        Budg["预算（类似 cgroups）<br/>token bucket · 分组"]
        Hooks["生命周期钩子<br/>guard · rag · memory · cache"]
        Ipc["IPC 与系统调用<br/>spawn · fork · send/recv"]
    end

    subgraph providers["⚙️ 推理（类似 CPU）"]
        Router["模型路由<br/>与推理缓存"]
        Llm["LLM<br/>OpenAI 兼容 · DeepSeek · Ollama"]
    end

    subgraph tools["🔧 工具（类似 I/O 设备）"]
        Web["网络 · 网站 · 浏览器"]
        Know["搜索归档（BM25）· PDF · 文档"]
        Db["SQL · DuckDB · 文件"]
        Act["脚本 · 子代理 · 邮件 · S3"]
    end

    subgraph store["💾 存储"]
        Transcripts["对话记录"]
        Events["事件日志（审计）"]
        State["State store"]
    end

    subgraph modules["🧩 模块——内核之上的功能"]
        Wf["Workflow (DAG)"]
        Analytics["📊 对话分析"]
        Approvals["Approvals · 升级"]
        Connectors["连接器（OAuth）"]
    end

    Widget --> Host
    Messengers --> Host
    Api --> Host
    Email --> Host
    Cron --> Host
    Webhook --> Host
    Monitor --> Host
    Host --> Sched
    Sched --> Processes
    Processes --> Ctx
    Processes --> Budg
    Processes --> Hooks
    Processes --> Ipc
    Hooks --> Router
    Router --> Llm
    Processes --> Web
    Processes --> Know
    Processes --> Db
    Processes --> Act
    Processes --> Transcripts
    Processes --> Events
    Processes --> State
    Events -.-> Analytics
    Hooks -.-> Approvals
    Ipc -.-> Wf
    Act -.-> Connectors

核心原则：

代理即进程。 每个代理都作为独立进程启动，拥有自己的 PID、上下文、工具集和预算。代理模板（agent.yaml）是配方；进程是惰性创建的，在首次请求时创建。工作流和子代理也是进程，具有 spawn/fork 语义。
内核即秩序。 一个异步运行时调度所有进程，维持并发限制并分配预算（token bucket、按用户和会话分组）。内核中介每一次工具调用：验证参数、限制时间、记录日志并计算成本。
模型是可更换的处理器。 内核本身不进行推理，而是将其调度到可插拔的提供者上（OpenAI 兼容 API、DeepSeek、Ollama）。模型路由根据请求选择模型，推理缓存消除重复调用。
通过钩子实现可管控性。 钩子在“消息前/后、工具调用、推理、令牌流、上下文压缩”等点拦截生命周期。由此实现 DLP 和个人数据脱敏（guard、pseudonymize）、回答接地（groundedness）、记忆（memory）、RAG（rag）、缓存（faq_cache、tool_cache）、循环中断（loop_guard）。
模块化。 内核只是机制；功能（workflow、cron、渠道、分析、连接器、记忆、模型路由、文档）是独立模块，通过统一的服务接缝接入内核。被禁用的子系统会响应“未配置”，而不会破坏平台。
通过触发器实现自主性。 代理不仅由消息启动：cron——按计划，webhook——由外部 push，monitor——在新数据出现时（RSS）。结果进入 sink：webhook、Telegram、email、另一个代理。
控制与隔离。 智能体不会读取他人的上下文，也不会消耗他人的预算。所有步骤都会写入转录和事件日志（审计）。工作知识库是 BM25 搜索档案；对外部数据库和系统的访问只能通过工具进行，可配置只读和确认。

结论

面向企业的 AI 智能体不是魔法，也不是炒作。它是一种工程解决方案，将三样东西缝合在一起：

模型 —— 理解自然语言的大型语言模型。
公司数据 —— 文档、数据库、规章制度、商品目录。
渠道 —— 网站、Telegram、VK、Yandex Messenger、email —— 用户所在之处。

结果：员工和客户在几秒内获得答案，企业节省数百万，分析师终于从事分析工作，而不是做数据导出。

而这一切——回本周期从一周起。