备注先说明写这篇文章的前提最近刷到多篇技术栈文讨论关于harness可插拔以及jev决策技术和Spring AI AlibabaSAA停更谣言等的讨论我根据自己见解以及接触到的知识点和自己改造过的传统java项目进行总结根据AI分析排版了这篇文章。版本架构方法论版适用于 Java / Spring Boot 为主的企业级 AI 应用也适用于 Python 等技术栈。本文不绑定任何具体业务项目。案例仅用于说明架构推演方法正文核心是架构演进、概念边界、可插拔设计和工程落地原则。一、核心结论AI 系统的核心问题不是选择哪个 AI 框架而是如何把 AI 能力组织成稳定、可治理、可替换的系统。业务核心仍由领域模型、业务服务、事务、权限、数据一致性和确定性规则负责。LLM、Agent、Workflow、Decision、Memory、RAG、Tool 等属于 AI 能力应通过清晰边界进入业务系统。SAA、AgentScope、JEV、MCP 都不应成为业务架构的核心它们更适合作为能力实现或基础设施。真正的可插拔不只是增加插件而是让 Agent、Workflow、Decision、LLM、Tool、Memory 等能力的实现可以替换。Agent 不等于业务系统也不应直接成为业务真相的拥有者Agent 应通过 Tool / Application Service 操作业务核心。二、从传统软件架构到 AI 架构2.1 传统业务系统User → Controller/API → Application Service → Domain → Repository → DB这种架构适合规则明确、流程稳定、数据结构化的系统优势是确定性、可测试性和事务一致性。2.2 AI 带来的新问题输入扩展到自然语言、图片、文档、语音等非结构化数据。需要意图理解、规划、工具选择、上下文管理和多轮交互。部分决策具有概率性。任务可能需要多个步骤、工具甚至多个 Agent 协作。模型、Prompt、Context、Memory、Tool 和执行环境成为新的运行时依赖。2.3 第一原则AI 应增强业务系统而不是取代业务系统的确定性核心。AI Layer → Tool / Application API → Business Core → DB三、AI 应用的能力分层层级主要职责典型实现Interaction用户交互、会话、输入输出Web / App / Chat / APIAgent理解任务、规划、选择动作、循环执行AgentScope / SAA Agent / 自研Workflow固定或半固定流程编排Graph / Workflow Engine / SAADecision结构化判断、分类、策略决策Rule / JEV / LLM Structured OutputLLM语言理解、生成、推理、结构化输出云模型 / 本地模型Tool查询和执行外部能力MCP / HTTP / Java ServiceContext Memory上下文、会话、长期记忆、状态Redis / DB / Vector DBKnowledge / RAG知识检索、文档理解Search / Vector DB / RAGSandbox代码、文件、隔离执行Container / SandboxBusiness Core业务规则、事务、权限、状态、数据Spring Service / Domain / DB四、Agent 与 HarnessAgent 不应理解成“一个调用 LLM 的类”。更准确地说Agent 是围绕目标持续理解、决策、行动、观察和调整的运行单元。Goal → Understand Context → Decide → Choose Tool → Execute → Observe → Continue / Stop / Ask HumanAgent 因此天然需要 Runtime。Harness 可以理解为 Agent 的运行时外壳组织模型、工具、上下文、记忆、执行环境、策略、验证和观测。Agent Model Runtime CapabilitiesHarness Runtime / Coordination Layer五、Harness 的可插拔维度维度可替换内容价值Model不同模型供应商、本地模型降低模型锁定AgentAgentScope、SAA Agent、自研替换 Agent RuntimeWorkflowGraph、Workflow Engine、自研替换编排实现DecisionRule、JEV、LLM、Hybrid替换决策机制ToolMCP、HTTP、Java Service替换能力接入MemoryRedis、DB、向量库替换记忆实现KnowledgeRAG、Search、Knowledge Base替换知识来源Sandbox容器、代码执行环境隔离执行Policy权限、审批、预算、工具白名单控制 Agent 行为ObservabilityTrace、日志、评估、审计治理与可观测传统插件通常是在稳定宿主中增加某个功能Harness 的可插拔更偏向运行时能力的组合和替换。六、SAA 与 AgentScope 的正确关系两者不是简单的上下位关系也不是“一个负责业务、一个只能做工具”。两者都可以接 LLM、Tool、Agent 和业务系统。维度SAAAgentScope主要定位Spring / 企业 AI 应用与编排Agent Framework / Agent Runtime更自然的视角应用 / 流程为中心Agent 为中心适合Spring Boot 企业应用、Workflow、Graph、业务集成Agent 行为、Runtime、Multi-Agent、长任务业务交互可以可以LLM / Tool可以可以是否必须二选一不是不是不要形成“AS工具项目、SAA业务项目”的误解。更准确的是二者都是 AI 能力实现方式可以单独使用也可以组合使用。七、为什么 SAA 可以引入 AgentScope不是因为 SAA 不会做 Agent而是不同框架积累了不同的 Agent Runtime 能力。SAA 可以把 AgentScope 作为一种 Agent 实现接入自己的应用编排体系。SAA Application / Workflow↓Agent Adapter↓AgentScope Agent↓LLM / Tools / Memory这类似于 Spring Boot 可以组合不同 ORM 或基础组件宿主框架并非完全无法实现能力而是为了复用更适合的既有实现。八、真正推荐能力抽象而不是框架绑定顶层不要直接依赖 AgentScopeAgent、SAAAgent 等具体类型而应定义自己的能力接口。public interface AgentEngine {AgentResult execute(AgentRequest request);}public interface WorkflowEngine {WorkflowResult execute(WorkflowRequest request);}public interface DecisionEngine {DecisionResult decide(DecisionContext context);}public interface LLMService {LLMResult chat(LLMRequest request);}public interface ToolExecutor {ToolResult execute(ToolRequest request);}AgentEngine├── AgentScopeEngine├── SAAAgentEngine└── CustomAgentEngineDecisionEngine├── RuleDecisionEngine├── JEVDecisionEngine├── LLMDecisionEngine└── HybridDecisionEngine业务层依赖能力接口基础设施层依赖具体框架这样可以降低框架锁定。九、AS、SAA、JEV、MCP 的层次关系AI Application├── Agent → AS / SAA / Custom├── Workflow → SAA / Custom└── Decision → Rule / JEV / LLM↓Tool Layer → MCP / API / Service↓Business Core↓DBAgentScope 与 JEV 不属于同一层AS 更偏 Agent RuntimeJEV 更适合被抽象成结构化 Decision Engine 的一种实现。MCP 主要解决工具/能力的协议化接入。十、Agent 决策与业务决策必须区分Agent 决策下一步查什么、调用哪个工具、是否继续、是否请求人工确认。业务决策税额、库存、权限、状态、交易合法性等应由确定性业务核心负责。结构化决策从固定类别中选择、风险判断、策略选择可由 Rule、JEV、结构化 LLM 或 Hybrid 实现。推荐原则Agent 决定“做什么”Decision Engine 辅助决定“具体选什么”Business Core 最终决定“什么是合法且有效的业务操作”。十一、推荐企业级总体架构User / API↓AI Application├── Agent Layer → AgentEngine → AS / SAA / Custom├── Workflow Layer → WorkflowEngine → SAA / Custom├── Decision Layer → Rule / JEV / LLM├── Context / Memory└── Tool Layer → MCP / API / Service↓Business Core↓DB十二、如何根据项目本身推演架构识别确定性流程与需要自然语言/概率判断的环节。确定业务真相规则、状态、权限、交易和数据一致性由谁负责。把AI 需要访问或操作的能力整理为 Tool / Application Service。固定流程优先Workflow动态任务优先 Agent。结构化判断抽象Decision Engine。最后再选择SAA、AgentScope 或其他实现而不是反过来。补齐权限、审批、审计、评估、可观测、幂等和故障恢复。十三、典型项目的架构推演案例 A简单 CRUD以传统 Spring Boot 分层为主AI 可以作为可选助手不必为了 AI 强行引入 Agent。Spring Boot → Application Service → Domain → DB↑AI Assistant可选案例 BAI Research / 数据分析工具用户给目标系统动态拆解任务、搜索、执行代码、调用工具并生成报告Agent Runtime 的价值较高。User → Agent Runtime → Search / Code / Tools → Report案例 CERP / CRM / 财务类系统业务核心继续采用领域架构AI 负责自然语言入口、数据理解、建议、异常解释和受控操作。Business Core AI Agent Workflow Decision Tools案例 D固定流程的智能审核流程稳定时 Workflow 更重要LLM 负责抽取与理解Decision/Rule 负责约束人工负责必要复核。Workflow → LLM Extraction → Decision → Human Review → Business Service案例 E复杂 Multi-Agent 平台研究、代码执行、长任务自动化等场景可以建设完整 Harness包含 Agent Runtime、Memory、Sandbox、Subagent、Tool Registry、Policy 和 Observability。十四、Workflow 与 Agent 如何选择特征更适合原因步骤固定、状态明确Workflow可预测、可审计、易测试目标明确但路径不确定Agent需要自主规划与工具选择固定主流程 局部动态任务Workflow Agent隔离确定性与不确定性纯分类、评分、策略选择Decision Engine无需完整 Agent Loop简单 CRUD传统业务架构Agent 引入价值有限十五、企业 AI 的确定性边界概率性世界LLM / Agent / RAG / 推理↓Tool API↓确定性世界Domain / Rule / Transaction / Permission↓DBLLM 可以提出建议但不能成为财务、库存、权限等业务真相的最终来源。Agent 可以规划动作但关键业务操作必须经过业务服务校验。AI 输出尽量结构化并设置置信度、校验和人工确认。关键副作用操作应具备幂等、审计和回滚策略。十六、可插拔设计的边界不是所有代码都必须抽象。稳定且可能替换的基础能力适合抽象稳定的业务领域能力应该直接表达业务语义避免为了理论上的替换增加无意义接口。不推荐AgentScopeAdapter.execute(ReActAgent agent)推荐AgentEngine.execute(AgentRequest request)十七、推荐代码分层com.example├── ai│ ├── api│ │ ├── AgentEngine│ │ ├── WorkflowEngine│ │ ├── DecisionEngine│ │ ├── LLMService│ │ └── ToolExecutor│ ├── application│ ├── domain│ └── infrastructure│ ├── agentscope│ ├── springai│ ├── llm│ ├── mcp│ ├── memory│ └── rag└── business├── domain├── application└── infrastructure十八、架构演进路线阶段 1传统业务 AIBusiness Core LLM / RAG Assistant阶段 2Tool 化AI → Tool → Business Service阶段 3AgentGoal → Agent → Tool Loop → Business Core阶段 4Agent Workflow DecisionAgent / Workflow / Decision / Tool / Memory 分层阶段 5AI HarnessAgent Runtime Workflow Decision Context Memory Tool Registry Policy Sandbox Observability Evaluation十九、技术选型原则场景原则Spring Boot 企业应用优先考虑 SAA / Spring AI 生态集成价值Agent 行为复杂可考虑 AgentScope 等 Agent Framework固定流程多Workflow / Graph 优先结构化决策多Rule / Decision Engine可接 JEV模型可能更换抽象 LLM Provider跨语言优先协议化接口如 HTTP / MCP / A2A高风险业务操作Tool Business Service Policy Human Approval长期建设 AI 平台建立自己的能力接口避免业务层暴露框架类型二十、常见错误把 Agent 当成整个业务系统。让 Agent 直接操作数据库。认为 SAA 与 AgentScope 必须二选一。认为 AgentScope 只能做工具项目。把 JEV 当成 Agent Runtime。为了可插拔而过度抽象。用 Agent 替代本来确定的 Workflow。没有权限、审计、幂等和人工确认就开放副作用 Tool。先选框架再倒推业务架构。把 Prompt 当成业务规则唯一实现。二十一、最终架构判断框架系统的核心业务真相是什么哪些操作必须确定性执行哪些环节真正需要LLM哪些任务需要Agent 动态规划哪些流程更适合Workflow哪些判断应该独立成Decision EngineAI 需要哪些 Tool哪些Tool 有副作用是否需要审批和权限哪些AI 基础能力未来可能替换业务层是否已经与具体AI 框架解耦二十二、最终方法论不要问“这个项目应该用 SAA 还是 AgentScope”应该问“这个项目需要哪些 AI 能力”不要问“Agent 能不能做业务”应该问“哪些决策由 Agent 负责哪些业务真相由 Business Core 负责”不要问“JEV 是不是 Agent 的一部分”应该问“这个项目有没有需要独立抽象的 Decision 能力”不要问“Harness 是不是一个插件系统”应该问“我的 AI Runtime 有哪些能力需要独立演进和替换”最终目标不是选择一个“最强框架”而是建立稳定的能力边界业务核心保持确定性AI 能力通过接口和协议进入系统Agent、Workflow、Decision、LLM、Tool、Memory 等能力可以独立演进。SAA、AgentScope、JEV、MCP 最终都回归到它们应有的位置技术实现而不是业务架构本身。
