FinXScope 是阿里云新金融技术服务团队基于 AgentScope Java 构建的金融级 AI 原生智能体底座。作为整个 Agent Harness 体系的核心组成部分，FinXScope 充分复用 AgentScope Java 在智能体编排、工具集成、多模型接入及可扩展运行时等方面的成熟能力，并在此基础上针对金融行业的合规性、安全性与高可用要求进行了深度定制与增强。完整的 Agent Harness 体系由 FinXScope 运行底座、AI 服务资产平台、全链路评测平台和运营管理平台共同构成，FinXScope 在其中承担着最核心的智能体运行与管理职责。理解 FinXScope 的核心定位，需要把握四个关键层面：
一句话概括：FinXScope 是金融级 AI 原生智能体底座的核心引擎。专家服务团队与金融机构深度共创，围绕企业实际场景共同打造符合金融级要求的 AI 原生应用搭建、运行与运营体系。基于它构建的智能体应用，让用户只需一句话描述目标，系统即可自主规划路径、动态调度上百个技能完成任务，真正实现“对话即服务”的全新交互范式。
自推出以来，FinXScope 获得多家金融机构的高度关注和实质性合作进展。覆盖国有大行、股份制银行、保险公司及证券机构等多类金融业态。
实际落地场景涵盖财富管理、客户经理赋能、智能核保、合规审查、投研分析等核心金融业务。在已投产的项目中，AI 原生 App 已触达千万级用户群体，验证了 FinXScope 在真实生产环境下的稳定性和业务价值。
这些实践验证了一个核心判断：金融机构需要的不是又一个聊天机器人框架，而是一个能够真正支撑企业级智能体从概念验证到规模化投产的运行底座。
▍2.1 从“功能导航”到“对话即服务”的范式跃迁
金融 AI 正在经历一次根本性的范式变化。2024 年以来，以 Manus、Claude Code、Hermes Agent 等为代表的自主智能体产品引爆了全球市场的关注，OpenClaw 在 3 个月内获得超过 23 万 GitHub Stars 成为现象级项目。这些标志性事件证明：大模型已经从“聊天助手”进化为能够自主规划和执行复杂任务的“工作搭档”。
对金融行业而言，这个变化的影响是深远的。传统的智能服务研发路径是在已有系统上“叠加”AI 能力：AI 的定位更像是帮助传统工作流的辅助工具，它没有打破原有的服务路径。用户依然需要在层级菜单、按钮和表单间手动跳转，只不过多了一个“AI 问答”入口。这种方式导致了一个尴尬的局面：客户用了所谓的“智能服务”，但使用方式和体验与传统模式并无本质区别。
但随着大模型能力跨越临界点，AI 已经具备参与甚至主导业务流程的能力。这意味着金融机构对 AI 的期待发生了根本性转变：不再是简单地自动化固定工作流，而是希望 AI 能够自主理解用户意图、动态调度企业级金融服务资产、解决客户的复杂问题。
这个跃迁的本质是：从“以企业功能为中心”转向“以用户问题为中心”——用户不再需要知道系统有哪些功能、该走哪个流程，而是直接描述自己的目标，AI 自主完成从理解到执行的全过程。这就是“对话即服务”的新范式。
据安永《AI 银行白皮书》分析，AI 技术在银行业的规模化落地已具备战略紧迫性。普华永道 2026 年金融 AI 调研也指出，银行与保险机构在 AI 治理方面最关注的是可追溯性与可解释性。然而，金融机构在从 POC 验证走向规模化投产的过程中，面临着一系列深层次的结构性挑战，而这些挑战恰恰是 FinXScope 所针对性解决的：
上述挑战的本质是一个系统性问题：金融机构需要的不是某个单点能力的增强，而是一套完整的智能体运行底座。
一个容易被忽视的事实是：智能体的最终业务效果，并不完全取决于大模型本身的能力，同样取决于承载它运行的底座（Agent Harness）的质量。 意图是否被精准理解、工具是否被正确调度、上下文是否被有效管理、执行过程是否可靠可控——这些“模型之外”的工程能力，才是决定智能体能否在真实场景中稳定交付价值的关键。同一个大模型，运行在不同质量的底座之上，呈现的业务效果可能天差地别。这正是金融机构需要一套专业级 Agent Harness 的根本原因。
FinXScope 是整个 Agent Harness 体系的核心引擎，也是首个面向金融行业的企业级智能体运行底座。 它提供的是系统性的完整能力组合，而非散点式的技术组件：基于已在阿里巴巴大规模验证的 AgentScope 框架，叠加完全自研的十大核心能力和金融级增强，形成了一个既有坚实技术根基、又能快速适配金融场景的智能体运行平台。围绕 FinXScope，Agent Harness 体系进一步延伸出 AI 服务资产平台（FinXSkillHub）、全链路评测平台（FinXVantage）和运营管理平台，共同覆盖智能体从开发、运行到持续优化的完整生命周期。而 FinXScope 的六层架构，不仅是这套体系的技术实现骨架，更是面向 AI 原生时代对企业应用架构的全新定义与规范。
为什么需要重新定义企业架构？ 传统企业架构（SOA、微服务）是围绕“人操作系统”的范式设计的：人通过界面发起操作，系统按照预设流程执行，返回确定结果。但在 AI 原生范式下，“AI 自主规划和执行任务”成为核心驱动力。这要求所有的服务能力、数据资产、功能组件都必须面向“如何更好地被 AI 理解和调用”而重新组织。这是一次底层设计范式的转变，而非在原有架构上的修补。
六层架构的意义远超技术实现层面，它回答了金融机构在智能化转型中面临的一个根本性问题：当 AI 从“辅助工具”升级为“核心驱动力”时，企业的技术架构应该如何重新组织？
以下十大核心能力是 FinXScope 的技术护城河，它们既包含完全自研的原创能力，也包含在 AgentScope 基础上进行深度增强。这些能力源自实际金融客户场景的刚性需求，经过了多个生产环境的打磨验证。
在意图树路由之外，意图引擎还支持基于 Skill 文档的 LLM 自主规划模式。当用户问题无法被意图树精确匹配时，系统自动切换到 LLM 自主规划：大模型基于 SkillPool 中所有可用技能的文档描述（SKILL.md），自主判断需要调用哪些技能、以何种顺序执行。两种模式在同一智能体中共存，由引擎根据问题特征自动路由。
▍4.2 三层记忆系统：从提示词工程到上下文工程的进化
- 解决方案：提示词工程关注的是“如何写好一个提示词”，而上下文工程关注的是“如何系统性地管理 LLM 接收到的所有上下文信息”：上下文的质量和组织方式，直接决定了智能体的决策质量。 三层记忆不是三个独立的“存储箱”，而是一套完整的“存储→压缩→召回→注入”运行循环：
- 短期记忆（STM）：对话级上下文的窗口管理与智能压缩。 STM 采用滑动窗口机制管理当前会话的对话轮次。当对话持续进行、上下文逐步膨胀超过 Token 阈值时，STM 触发智能压缩：优先使用 LLM 摘要（让大模型提取对话中的关键信息和决策要点，压缩为简洁的摘要），规则摘要作为回退策略（按时间衰减丢弃较早的低重要性消息）。压缩后的摘要替代原始消息继续参与对话，确保每次注入模型的上下文既保留了关键语义，又不会因过长而影响推理质量。多维度容量控制（轮次限制、Token 限制、时间限制）协同工作。
- 2.0 升级：STM 支持 Redis 持久化，实现跨实例会话恢复。
- 长期记忆（LTM）：跨会话知识的结构化存储与语义召回。LTM 基于 PostgreSQL + pgvector 实现持久化向量存储。在每次对话结束后，系统自动评估本次交互中哪些信息具有长期价值（通过 LLM 驱动的重要性评分，过滤冗余和低价值内容），将有价值的信息向量化后存入 LTM。在新对话开始时，系统将当前用户输入向量化，通过语义相似度检索，召回与当前对话最相关的历史片段（如“用户上周咨询过的基金产品”“用户表达过的投资偏好”）。同时支持关键词检索（带时间衰减评分）作为补充通道，向量检索失败时自动降级。召回的记忆片段被注入到当前对话的上下文中，让智能体“记住”跨会话的关键信息。
- 2.0 升级：LTM 完整迁移到 PostgreSQL，支持集群化部署。
- 用户画像（UserProfile）：构建在 LTM 之上的结构化金融属性层。 UserProfile 不是第三类独立“记忆”，而是从长期交互中自动提取和更新的结构化用户认知。它将 LTM 中散落的交互信息提炼为标准化的金融属性：静态属性（年龄、职业、资产规模）、动态属性（风险等级变化、投资偏好演进）、行为偏好（交互风格、决策习惯）和标签体系（高净值、稳健型、关注科技板块等）。每次交互自动更新，整体画像注入系统提示词指导对话策略。UserProfile 的运行时注入让不同用户获得完全不同的服务策略——同样问“推荐基金”，保守型和激进型用户获得的产品组合和话术完全不同。
异步零感知：三层记忆的读写操作完全异步化，不影响主流程的响应速度。用户感知到的是即时响应，系统在后台默默完成记忆的评估、压缩、存储和画像更新。
核心创新：共享执行底座使两种模式深度融合。 实现两种执行模式本身并不是最难的部分。真正的技术亮点在于：OneAgent 和 Multi-Agent 共享同一套统一执行引擎（AgentProcessEngine）作为底座。这意味着两种模式在权限校验、审计留痕、执行管理等横切关注点上保持一致，不会因为切换执行模式而丧失金融级保障能力。
正是因为共享执行底座，FinXScope 才能实现更进一步的创新——工作流挂载到 OneAgent。通过 MountableResource 机制，将 Multi-Agent 工作流封装为 Tool，供 OneAgent 在自主推理过程中按需调用。AI 自主决策何时需要启动一段确定性工作流（如合规审查子流程），工作流执行完毕后结果返回给 OneAgent 继续推理。这种“自主智能 + 确定流程”的融合之所以能够实现，正是因为两种模式运行在同一套执行引擎之上——上下文可以无缝传递、事件可以跨模式透传、审计可以统一记录。支持工作流挂起/恢复和子流程事件透传（避免主 Agent 复述导致的信息衰减和时延增加）。
- 场景痛点：每个智能体各自实现执行逻辑，导致代码重复、行为不一致、审计不完整，在金融级场景中这是不可接受的合规风险。不同 Agent 的上下文装配方式参差不齐，记忆读写时机不统一，异常处理链路各行其是，使得全链路日志无法穿透、工具调用缺乏统一拦截，既无法满足“每一步决策可回溯”的审计要求，也极大增加了多编排模式下的维护与演进成本。
- 解决方案： AgentProcessEngine 作为统一执行入口，整个引擎包含前置通用层、策略路由层、后置通用层，形成“统一入口 → 统一调度 → 统一收官”的闭环架构：
- 权限校验：用户-Agent-Skill 三级权限验证。
- 输入预处理：文件 ID、运行标识统一补齐，保证后续任何一层都能拿到完整可追踪的输入。
- 上下文加载：从历史消息装配短期记忆（STM），从 MemoryManager 召回相关长期记忆（LTM），从用户画像读出风险偏好等静态属性，统一注入执行上下文。
- 审计启动：打开全链路结构化日志、记录意图决策链与耗时度量，为后续拦截点提供统一的上下文锚。
- 灵活策略选择：根据 patternType 自动选择执行策略（OneAgent ReAct / Multi-Agent 八种编排）处理 。
- MountableResource 生命周期：记忆管理器、Toolkit、Skill 包、预编译图等“可挂载资源”按需在策略启动时接入、结束时释放，由执行上下文统一托管。
- 结果格式化：所有策略的输出统一收敛为标准的 AG-UI 事件流，对前端是一套协议。
- 记忆写入：用户原文 + 助手完整回复 + 元数据（session、改写文本、意图类型、命中 Skill、工具调用明细）异步回写 STM / LTM / UserProfile，用户画像随每次交互持续打磨。
- 审计关闭：闭合未结束的流式消息段、发送终态事件、打印结构化日志（实例、模式、耗时、文本长度），与前置层的 traceId 完成闭环。
- 指标采集：Prometheus 指标端点已打通，采集引擎总耗时、各阶段耗时、LLM 调用量等指标。
全面支持同步、流式、AG-UI 三种执行模式。完整拦截器链（12 个拦截点）支持自定义逻辑注入。执行全程自动记录决策链、工具调用、Skill 日志，满足金融审计合规要求。
- 2.0 新增： 模型运行时覆盖、Skill 级超时配置和重试策略、执行上下文跨实例透明迁移。
- 模型运行时覆盖：系统提示词、模型类型、skills等支持热更新，同一个 Agent 配置可按用户/场景动态变身。
- Skill 级超时与重试：按 Skill 粒度配置独立超时阈值与重试策略，避免长尾工具拖垮整条对话链。
- 执行上下文跨实例透明迁移：支持多副本部署下请求路由到任意实例都能恢复状态，为灰度发布与故障切换提供底座。
▍4.5 AG-UI 全链路流式交互：跨渠道一致的实时服务体验
- 场景痛点：传统 AI 应用“问一句等半天”的交互模式让用户无法感知 AI 正在做什么。多渠道各自定制交互协议导致体验不一致和管理成本高。同时有些金融数据是结构化的，纯文本输出无法有效传达趋势、对比、占比等信息。
- 解决方案：FinXScope 全面适配 AG-UI 标准协议，基于 Spring WebFlux 响应式流式架构，通过 SSE（text/event-stream）实现全链路异步流式传输。AG-UI 协议定义了 15 种细粒度事件类型，覆盖推理过程、工具调用、中间结果、最终输出等完整交互链路。AG-UI 标准化交互带来四重核心价值：
- 跨渠道复用：新渠道接入时，前端只需按统一标准消费 AG-UI 事件流，无需为每个渠道单独定制交互协议。同一套事件流在各渠道前端直接复用，显著降低管理成本和开发成本，确保跨终端一致的智能服务体验。
- 前后端解耦：前端只消费标准事件流，后端切换模型、增减工具、调整策略时前端无需任何改动。这让后端可以独立快速迭代，前端只需维护对标准事件类型的渲染能力。
- 统一可观测：所有 Agent 基于同一套事件类型做监控、告警和性能分析。事件流天然提供了全链路的执行追踪能力。
- 工具生态可扩展：新增工具只需按协议输出标准事件，即可被前端自动识别和消费，无需跨团队联动改造。
渲染层面内置多种标准渲染工具（折线图、柱状图、饼图、指标卡片、数据表格、成交量图、可选列表、确认操作卡片等），支持占位符式增量渲染和个性化组件扩展。
- 2.0 新增： workflow_command_agent 自然语言到控件操作指令转化；WorkflowToolRegistry 前端动态声明控件、运行时注册为智能体可调用工具。
▍4.6 三层技能定义体系：从配置到代码的渐进式复杂度适配
- 场景痛点：金融业务技能复杂度跨度大，从简单的汇率查询到复杂的信贷审批，单一定义方式无法兼顾简洁性和表达力。
- 解决方案：三层技能定义体系按复杂度递进：
- YAML 配置文件（轻量查询类）：在配置文件中声明技能名称、描述、关联工具和内容。框架启动时自动读取并批量注册，无需编写任何代码。适合汇率查询、余额查询等内容固定、逻辑简单的技能。
- SKILL.md + 脚本（中等复杂度，“文档即契约”）：在 skills目录下为每个技能建立独立文件夹，核心是一份 SKILL.md文档，可配套 Python/Shell 脚本使用。OneAgent 完全依赖这份 Markdown 文档决定何时调用该技能、如何传参，让行为可预测、可审计。适合客户洞察、产品推荐、风险评估等中等复杂场景。
- Java @Bean 注册（复杂业务逻辑）：标准 Spring Bean 方式，具备完整类型检查和 IDE 支持，同时作为底层工具的注册方式（如多步事务封装、强一致性保障的业务工具）。适合多步事务封装、合规审查、信贷审批等强一致性业务场景。
- SkillsHub 远程加载：由管理平台统一管控版本。服务启动时全量拉取上线技能，运行期间管理平台发布变更，整个过程无停机时间，支持版本管理和灰度发布。
- 技能自动权限过滤：支持NONE、FILTER、REJECT三种模式管控用户对于技能的使用权限。
▍4.7 工具与知识对接：标准化连接企业存量资产
- 场景痛点：金融机构经过多年信息化建设，积累了大量业务系统和知识资产，但它们接口标准各异、分散在不同平台中，逐个编写适配代码工作量大。与此同时，大量非结构化知识难以被智能体有效利用。
- 解决方案：通过标准化协议和配置化接入机制，将工具对接、知识检索和权限透传统一为平台级基础能力，最大限度减少适配改造工作量：
- 工具接入：提供 MCP（Model Context Protocol）和 API Schema 两种标准配置方式，企业只需声明服务地址和认证信息即可完成工具注册。McpClientRegistry 统一管理所有 MCP 连接的配置、健康检查和生命周期，确保工具可用性；同时支持配置化接入任意符合 MCP 协议的客户自定义 Bean，无缝对接客户存量系统能力，无需额外开发。
- 知识接入：统一的 Knowledge 接口支持多知识源的配置化路由——百炼通用 RAG、点金金融专业知识库、客户自建知识库均可通过配置接入。智能体通过统一的 Knowledge 工具调用知识检索，底层自动屏蔽不同知识库的实现差异，并对标签检索、召回重排、查询改写等核心能力提出统一的质量标准。
- 权限透传：无缝对接企业安全体系。 为工具调用和知识召回接口提供标准化的数据透传通道，支持身份信息、渠道标识等上下文的端到端传递，让智能体的每一次外部调用都自动继承用户的权限边界，无需重复建设鉴权逻辑。
- 2.0 新增：McpClientRegistry 支持动态管理：工具连接的增删改在运行时即可完成，秒级生效，无需重启服务；新注册的工具自动注入到 Agent 可用列表，运营团队可以独立完成工具的上下线操作。
▍4.8 接入网关引擎：多渠道统一入口与安全管控
- 场景痛点：多渠道输入格式各异需要统一处理，AI 系统面临的 Prompt 注入等安全威胁需要在入口层统一防护。
- 协议碎片化：不同客户端（Web/移动端/第三方系统）提交的请求格式不同后端需逐一适配。
- 安全威胁：Prompt 注入、敏感内容输入、违规操作等安全威胁如不在入口层统一拦截，将扩散至意图引擎和执行引擎，造成不可控风险。
- 多模态预处理缺失：图片/视频/音频/文档等非结构化内容如果直接透传给 LLM，无法获得有效理解；需在网关层完成内容提取并增强 Prompt。
- 流式输出不一致：不同处理分支（纯文本/多模态/TodoList）的 SSE 事件格式和生命周期管理各自为政，前端对接成本高
- 会话状态管理松散：消息持久化、会话标题生成、上下文恢复等散落在各模块，缺少统一编排点。
- 解决方案：实现六重核心职责：协议适配、多模态处理、安全管控、请求路由、流式输出编排、会话持久化。集成完整拦截器链和权限检查。安全策略支持后台动态配置，变更秒级生效。
- 协议适配：兼容 4 种输入格式，统一解析为标准内部表示。
- 多模态处理：图片理解、视频理解、音频 ASR、文档解析，并行提取并增强 Prompt。
- 安全管控：策略匹配 + 风险评分 + 行动执行（pass/warn/block），支持白名单、5 分钟策略缓存。
- 请求路由：三路分发：纯文本 → OneAgent / 多模态 → 提取+OneAgent / TodoList → 直接执行。
- 流式输出编排：统一 AG-UI Protocol 事件格式，过滤重复控制事件，网关层统一发送生命周期事件。
- 会话持久化：用户消息/助手回复自动保存，会话标题自动生成，多模态内容兜底保存。
- 2.0 新增：DocumentParserService 多格式文档解析（PDF/DOCX/DOC/MD/TXT），支持大文件分块、格式保真、元数据提取，让用户可以直接基于上传文档与智能体对话，权限控制体系、TodoList 智能路由、可观测埋点。
▍4.9 TodoList 任务管理（2.0 全新构建）：长流程任务的可视化进度追踪
- 场景痛点：针对跨境汇款、贷款审批等长流程金融任务（耗时 30s 至数分钟），解决用户对 Agent 执行过程“完全不可见”的问题——不知道进展到哪、不知道拆解得对不对、中断后无法继续。
- 进度可见性：实时同步执行状态（如“2/4 完成，正在执行第 3 步”），消除等待焦虑，减少无效追问。
- 规划可校验：透明化 Agent 的任务拆解逻辑，允许用户在执行前/中识别遗漏或偏差并介入纠偏，变被动等待为主动审视。
- 中断可恢复：持久化存储任务状态，支持跨会话/跨天自动断点续传，保障复杂业务流程连续性。
- 解决方案：基于两级步骤模型 + Hook 自动注入 + Pipeline 状态同步，构建从规划到恢复的执行闭环。
- 两级步骤管理：Level-1 由 LLM 自主拆解顶层步骤序列（如“查询 → 校验 → 确认 → 转账”），通过 TodoListToolkit 提供的 7 个标准工具全生命周期管理 5 种状态；Level-2 由执行引擎在 Pipeline 层面自动填充，将并行调度的子 Agent 名称、任务及状态写入对应 Level-1 步骤的 subSteps，实现多智能体协作细节的可视化。框架内置一致性约束：强制通过 finish_todo_step 标记完成、同一时刻仅允许一个步骤处于 IN_PROGRESS 以防止并发混乱，步骤完成后引擎自动激活下一个 TODO 步骤，实现状态的自然流转，显著降低 Agent 的编排复杂度。
- Hook 自动状态注入（无感记忆）：通过 TodoListHintHook 拦截 PreReasoningEvent，在每轮 LLM 推理前动态追加包含固定工具说明与实时任务状态（如进度统计、当前/下一步骤详情）的系统提示，使 Agent 在无需独立记忆模块的情况下实现全局进度的“无感”感知，并在任务完成后自动引导进入总结阶段。
- Pipeline 策略的Multi-Agent 状态同步：基于 ParallelAgentStrategy 引擎监听子 Agent 的分配与完成事件，自动调用 updateTodoSubStepStatus 将状态同步至 TodoList 存储，使主 Agent 能通过 Hint Hook 即时感知子任务进展，从而实现零通信成本的高效 Multi-Agent 编排状态同步。
▍4.10 全链路配置热更新与运营管理平台（2.0 全新构建）：运行时秒级生效的持续优化
- 配置热更新：覆盖 Agent/Skill/Tool/意图树/模型/网关全部核心配置。Redis Pub/Sub 多实例同步，秒级生效。ConfigVersionRegistry 版本管理支持精确回滚。
- 运营管理平台：对智能体、技能、意图、工具及网关实现全生命周期管理：可视化编辑意图树、配置映射关系、注册/启停技能、管理 MCP 连接、配置安全策略。支持搭建镜像运行环境进行配置试跑验证，多版本对比评测后择优发布。未来与全链路评测体系打通，实现“配置→试跑→评测→择优发布”的自动化运营闭环。
▍5.1 AgentScope：为智能体而生的开发框架
AgentScope 是阿里巴巴开源的 AI 原生应用开发框架，专为构建自主规划智能体而设计。选择它作为底座框架，基于三个关键维度：技能动态治理（Tool Group 按需激活，避免上下文过载）、高并发架构（AgentPool 工厂模式天然无状态）、执行可靠性（指数退避重试、完整 Hook 系统实现熔断限流）。
Agent Scope 提供了坚实的基础框架能力，但通用框架到金融级产品之间仍有显著的能力鸿沟。FinXScope 在 Agent Scope 之上构建了六大扩展：
2.0 新增扩展：多智能体工作流引擎（八种编排策略）、工作流挂载机制（MountableResource）、配置热更新引擎（Redis Pub/Sub + ConfigVersionRegistry）、三级权限体系、可观测性框架（BizLogger + Prometheus + ObservabilityHook）、远端存储改造（完全无状态化）。
在金融行业，“高码还是低码”不是一个二选一的问题，而是“在什么阶段、什么场景用什么工具”的问题。两者本质上是同一个技术体系中的不同角色，服务于智能体从“想法”到“投产”的不同阶段。
低代码平台的核心优势与适用场景：可视化编排让业务人员直观参与设计；快速原型验证让想法可以很快的变为 Demo；所见即所得的调试体验让问题定位直观。低码平台是业务验证阶段的最佳选择，也适合变化频次较低、流程节点不长（5-10 步以内）、对可靠性容错率比较宽容的场景。
低代码面临的挑战：当场景涉及复杂工作流编排、多轮交互和跨会话状态管理、AI 自主规划、以及金融级生产保障时，低码平台的维护成本和构建复杂度急剧飙升。
FinXScope 选择高码路线解决低码难以覆盖的场景，同时极力降低使用门槛：
FinXScope 从设计之初将高可用内化为基础架构特性。最终的高可用保障依赖客户基础设施能力，但 FinXScope 确保自身不会成为高可用瓶颈。
三级权限管控：用户 -Agent-Skill 三级权限，FILTER/REJECT 双模式，缓存优化，fail-open/fail-close 容错策略可配置。
输入安全：Prompt 注入防护、敏感词过滤、内容审核，策略支持后台动态配置。
全链路审计：决策过程、工具调用、Skill 日志完整留痕。MDC 上下文自动注入 traceId/spanId，全链路可追踪。
FinXScope 提供了一套覆盖接入、意图、以及智能体执行的全链路可观测体系，核心功能包括：
分布式链路追踪：基于 Micrometer Tracing 实现全链路追踪，自动为每个请求生成唯一 traceId，贯穿从网关接入到 Agent 执行的全生命周期。traceId 自动注入到所有日志输出中，支持跨异步线程的上下文传播，便于在分布式环境下快速定位请求链路和排查问题。
业务指标监控：通过 BizLogger 统一 API 实现业务埋点，自动生成 Prometheus 标准指标。指标体系按系统架构划分为六个层级（接入层、表现层、意图层、执行层、工具层、知识层），每层独立定义指标枚举，覆盖事件计数、耗时统计、活跃请求数、错误分类等维度。通过独立管理端口暴露 /actuator/prometheus 端点，供 Prometheus Server 拉取。
Agent 生命周期可观测：深度集成 AgentScope Hook 机制，通过 ObservabilityHook 追踪 Agent 执行的 5 个生命周期阶段：调用入口、LLM 推理、工具执行、摘要生成、异常处理。每个阶段自动采集耗时和 Token 用量，支持三级开关精细控制（全局开关 → 事件类型开关 → Agent 级覆盖），可在生产环境按需开启或关闭特定 Agent 或特定阶段的观测数据采集。
结构化日志：BizLogger 提供双模日志输出：每条业务日志同时以人类可读格式输出到控制台，以结构化 JSON 格式写入独立文件。日志自动携带 traceId、sessionId、userId 等上下文信息，支持机器解析和日志平台对接。
SPI 扩展机制：框架提供三层 SPI 扩展点，支持用户自定义可观测行为而无需修改框架代码。
日志输出扩展：通过注册自定义 BizLoggerProvider 替换或增补默认的日志处理逻辑。
Hook 注册扩展：通过实现 AgentHookProvider 为 Agent 注入自定义生命周期钩子。
数据提取扩展：通过实现 HookLogFormatter 自定义 Hook 事件的数据提取和格式化逻辑。
1. FinXScope支持两种使用方式：
2. FinXScope的运行态始终依附于具体的场景应用：
换言之，FinXScope 不存在脱离场景的独立“常驻运行”状态。部署规划应围绕实际的场景应用来制定。
3. 部署架构参考
4. 所需数据资源
项目运行依赖以下数据型资源。所有数据型资源优先复用客户现有的基础设施，仅在客户环境中无对应产品时才考虑单独部署。
核心原则：客户有什么用什么，不重复建设。数据型资源（PostgreSQL、Redis、向量库、OSS）全部优先对接客户既有基础设施，项目本身通过配置文件适配即可。仅在客户确实缺少某类资源时，才为其单独部署对应组件。
5. 资源预估参考
表中标注 (复用) 的资源，可考虑对接客户现有实例，无需单独部署。
粤ICP备14082021号
免费POC，
零成本试错
