3. 核心概念

3.1 Agent

Agent 是 FlowNex 中面向用户提供智能能力的执行主体。

一个 Agent 并不等同于一个大模型。Agent 是由模型、提示词、Skill、Tool、知识库、运行时策略、权限范围和上下文状态共同组成的业务能力单元。

Agent 可以具备：

  1. 默认模型配置。
  2. 默认风格。
  3. 默认 Tool 集合。
  4. 默认 Skill 集合。
  5. 默认知识库范围。
  6. 渠道接入配置。
  7. 运行时上下文策略。

在多 Agent 框架中，Agent 还可以承担不同角色，例如 Planner、Researcher、Executor、Reviewer 和 Synthesizer。

FlowNex 的目标不是只运行一个万能 Agent，而是让企业可以按业务场景配置不同 Agent，并在需要时让多个 Agent 协作完成复杂任务。

3.2 Conversation

Conversation 表示一次连续对话上下文。

它用于组织同一用户和 Agent 之间的多轮消息、任务、文件和状态。一个 Conversation 下可以包含多条 Message，也可以包含多个 Task。

Conversation 的主要作用：

  1. 保存多轮对话历史。
  2. 关联用户和 Agent。
  3. 支撑上下文恢复。
  4. 关联运行时实例。
  5. 关联任务和文件。
  6. 支撑跨轮追问。

需要注意的是，Conversation 不应被视为长期知识库。

长期、稳定、可复用的组织知识应进入知识库；运行时文件应进入 AGFS；可复用经验应进入 Memory、Skill 附录、知识草稿或评测集。Conversation 更适合保存当前对话过程和短期上下文。

3.3 Task 与 Task Step

Task 表示一次可执行、可追踪的 Agent 工作单元。

Task 可以由用户消息触发，也可以由定时任务、飞书入站消息、系统自动化或多 Agent Planner 触发。

Task 记录：

  1. 任务 ID。
  2. 会话 ID。
  3. 来源消息 ID。
  4. 用户 ID。
  5. 业务类型。
  6. 任务状态。
  7. 运行时配置。
  8. Skill 和 Tool 授权。
  9. 开始时间和结束时间。
  10. 最终结果。

Task Step 表示任务中的阶段性执行记录。

Task Step 可以记录：

  1. 当前步骤编号。
  2. 步骤类型。
  3. 步骤状态。
  4. 步骤内容。
  5. 关联文件。
  6. 开始和完成时间。

Task 与 Task Step 的设计让 Agent 执行过程具备结构化可观测能力。后续多 Agent 协作中，Task 还会进一步扩展为任务图节点。

3.4 Skill

Skill 是可复用的 Agent 专业能力单元。

它负责把一类任务的执行经验、约束和最佳实践固化下来，让 Agent 在面对专业任务时不只依赖通用模型能力。

Skill 通常包含：

  1. Skill 编码。
  2. 名称和描述。
  3. 适用场景。
  4. 执行策略。
  5. 输入输出约束。
  6. 可使用脚本或工作流。
  7. 依赖工具。
  8. 绑定知识范围。
  9. 审核、发布和安装状态。

Skill 与 Tool 的区别是：

  1. Tool 是可调用动作。
  2. Skill 是完成一类任务的方法。

例如，web_search 是 Tool，而“行业研究报告生成”是 Skill。该 Skill 可能会指导 Agent 调用 web_search、读取知识库、生成大纲、分析资料并输出报告。

Skill 与知识库的区别是：

  1. Skill 负责怎么做。
  2. 知识库负责依据什么做。

业务型 Skill 绑定知识库后，可以显著提升执行稳定性和可解释性。

3.5 Tool

Tool 是 Agent 可以调用的外部能力。

Tool 可以由 share-harness 内置，也可以由业务系统通过能力注册方式提供。

常见 Tool 包括：

  1. 文件读取。
  2. 文件写入。
  3. Shell 执行。
  4. Web 搜索。
  5. 远程文件搜索和恢复。
  6. 飞书文档、日历、审批、消息接口。
  7. 知识库检索。
  8. AGFS 文件操作。
  9. 企业内部业务 API。

在 FlowNex 中，Tool 需要被权限和运行策略约束。

toolCodes 表示本轮外部工具授权列表。基础文件工具和 runtime 内置能力不应简单混入外部授权列表，而应由 share-harness 运行时策略统一控制。

Tool 调用的结果应进入任务轨迹，并在必要时做输出裁剪、摘要化和错误映射，避免大体量工具输出污染模型上下文。

3.5.1 AI 应用、原子能力与 Skill 的关系

接入方案上线后，FlowNex 需要同时管理三类能力对象：

概念 定位 示例 与 FlowNex 的关系
AI 应用 面向业务场景的完整应用 请假助手、报销助手、瑞幸下单助手、数据分析助手 可以接入 FlowNex 作为一个业务入口、Agent 能力包或外部应用
原子化 AI 能力 可被复用的最小能力单元 OCR、合同条款识别、审批查询、订单创建、报表生成 注册到能力目录后由 FlowNex 统一授权、路由、观测
Skill Agent 面向任务的方法封装 合同评审 Skill、项目周报 Skill 可以调用一个或多个原子能力，也可以把原子能力包装成用户可理解的专业任务能力
Tool Agent 可执行的动作接口 approval_query、create_order、ocr_extract 可以来自 FlowNex 内置，也可以来自业务线 Capability Adapter

推荐边界如下：

  1. AI 应用回答“业务用户从哪里进入、完成什么场景”。
  2. Skill 回答“Agent 如何完成这类任务”。
  3. Tool 回答“Agent 可以执行哪些动作”。
  4. 原子能力回答“底层由哪个业务线或 Provider 提供稳定能力”。

为了避免能力接入后形成新的烟囱，FlowNex 需要引入以下核心对象：

对象 说明
Capability 平台统一管理的能力定义，包含编码、名称、版本、输入输出 Schema、能力类型、负责人和状态
Capability Provider 能力真实提供方，可以是业务线系统、算法服务、第三方平台或 FlowNex 自研服务
Provider Adapter control-center 内部的 Provider 适配实现，屏蔽不同 Provider 协议、鉴权、错误码和数据结构差异
Capability Gateway control-center 内部的能力调用治理入口，负责路由、鉴权、限流、审计、Trace 和降级
Tenant Capability Config 租户、部门、角色维度的能力开通、启停和配额配置

一个典型调用关系是：

前端 AI 应用
  -> ai-app-runtime-gateway /application/**
  -> ai-app-service
  -> control-center 能力中心
  -> Capability Gateway（control-center 内部）
  -> Provider Adapter（control-center 内部）
  -> 业务线 AI 能力 / 业务系统 API

对于 Agent / Skill / Tool 触发的原子能力调用，也同样进入 control-center 能力中心，再由内部的 Capability Gateway 和 Provider Adapter 完成治理与适配。这样设计后，用户侧不需要关心能力来自 FlowNex 自研还是业务线接入；管理员侧可以统一开通、授权、审计和运营；开发侧可以通过统一 Adapter 规范接入不同业务线能力。

3.6 Knowledge Base

Knowledge Base 表示可供 Agent 检索的组织知识库。

FlowNex 当前接入 OpenViking 知识库作为组织知识检索底座。本地系统只保存知识资产元数据、远端资源标识、可见范围和映射状态，不长期保存知识正文。

知识库可以包含：

  1. 制度。
  2. SOP。
  3. FAQ。
  4. 项目资料。
  5. 会议纪要。
  6. 交付模板。
  7. 历史案例。
  8. 产品说明。

Knowledge Base 的关键不是“把文档塞进去”，而是建立可治理的组织知识上下文：

  1. 哪些知识可被哪些租户使用。
  2. 哪些知识可被哪些角色访问。
  3. 哪些知识适合绑定到哪些 Skill。
  4. 哪些知识在运行时被命中。
  5. 哪些知识过期、低命中或召回质量差。

知识库的运行时访问通过 knowledgeAccess 控制。该对象由 control-center 根据用户授权、用户手选范围和 Skill 绑定范围计算后下发给 runtime。

3.7 AGFS Workspace

AGFS Workspace 是 Agent 执行任务时看到的文件工作区。

与普通本地临时目录不同，AGFS Workspace 具备以下能力：

  1. 跨实例访问。
  2. 多 Agent 共享。
  3. 文件版本历史。
  4. 文件级权限。
  5. 任务 checkpoint。
  6. 快照回滚。
  7. 文件血缘。
  8. 知识候选沉淀。

AGFS Workspace 的核心目标是让 Agent 像使用本地文件系统一样使用企业级共享文件系统。

从 Agent 或工具视角看，文件就是普通路径：

/workspace/project-a/requirements.md
/workspace/project-a/data/source.xlsx
/workspace/project-a/output/report.md

但在底层，这些路径会映射到 AGFS 的 space、mount、file node、object storage 和 version tree。

AGFS Workspace 是多 Agent 协作的关键基础设施。没有共享工作区，多 Agent 很容易退化成多个孤立对话；有了 AGFS，多 Agent 才能围绕同一批文件和任务产物真正协作。

3.8 Memory 与经验沉淀

Memory 表示从用户偏好、任务轨迹、长期交互和运行结果中沉淀出的稳定经验。

Memory 不等于聊天记录，也不等于文件全文。

合理的边界是：

  1. Conversation 保存对话过程。
  2. Knowledge Base 保存组织知识。
  3. AGFS 保存文件和产物。
  4. Memory 保存稳定偏好、经验、决策和长期上下文。

例如：

  1. 用户偏好“报告先给结论，再给数据依据”可以进入用户 Memory。
  2. 项目长期决策“该项目采用 Redis 绑定 runtime 实例”可以进入项目 Memory。
  3. 某个 Skill 高频失败原因可以进入 Agent 全局 Memory 或 runtime reminder。

经验沉淀不应无审计地直接改公共 Skill。推荐流程是：

任务轨迹 / badcase / 用户反馈
  -> 反思抽取
  -> 经验候选
  -> 审核或评测
  -> Skill 附录 / Runtime Reminder / 知识草稿 / Eval Case

3.9 Multi-Agent Task Graph

Multi-Agent Task Graph 表示多 Agent 协作时的任务图。

复杂任务通常不能由一个 Agent 单步完成。例如：

帮我基于项目资料、最近会议纪要和销售数据，生成一份客户经营分析报告，并检查是否符合公司模板。

这个任务可以拆成：

  1. Researcher 检索项目资料和会议纪要。
  2. Data Analyst 清洗和分析销售数据。
  3. Writer 生成报告。
  4. Reviewer 检查模板和风险。
  5. Synthesizer 输出最终版本。

Multi-Agent Task Graph 用于描述：

  1. 子任务之间的依赖关系。
  2. 每个子任务由哪个 Agent 角色负责。
  3. 子任务输入和输出。
  4. 子任务状态。
  5. 子任务使用的知识和文件。
  6. 失败后的重试、回滚或人工介入。

AGFS 是 Task Graph 的共享文件底座，Knowledge Base 是 Task Graph 的共享知识底座。

3.10 Capability Snapshot

Capability Snapshot 表示某一轮任务实际可用能力的快照。

它解决的问题是：

同一个用户、同一个 Agent，在不同时间、不同渠道、不同权限条件下，可用能力可能不同。

一次任务开始时，系统需要冻结本轮可用能力，避免执行过程中配置变化导致不可复现。

Capability Snapshot 通常包含：

  1. 当前可用 Tool。
  2. 当前可用 Skill。
  3. 当前知识库授权范围。
  4. 当前模型配置。
  5. 当前渠道能力。
  6. 当前运行时策略。
  7. 当前 AGFS workspace 或 mount 信息。

Capability Snapshot 对排障和审计非常重要。

当用户问“为什么这次没有使用某个 Skill”或“为什么没有查到某个知识库”时，平台可以基于快照回答：

  1. 该 Skill 当时未授权。
  2. 该知识库当时不可见。
  3. 该 Tool 当时未在本轮授权列表中。
  4. 该模型配置当时不支持某类能力。
  5. 该文件当时不在当前 AGFS workspace 中。