企业官网建设流程全解析

1. 项目概述：这不是又一个“调用大模型API”的Demo

“Spring AI Alibaba × Skill 整合实战：让 AI 真正‘会干活’”——这个标题里藏着三个关键信号，我拆开说给你听。第一，“Spring AI”不是Spring Boot的简单插件，它是Spring生态为AI原生应用设计的能力抽象层，把模型调用、提示工程、输出解析、流式响应这些重复劳动封装成可组合、可测试、可监控的Bean；第二，“Alibaba”在这里不是指某家云厂商的SDK包名，而是特指其开源的Spring AI Alibaba Starter，它深度适配了通义千问系列模型（Qwen）的推理协议、Token计费逻辑、Function Calling规范和本地化部署支持；第三，也是最容易被忽略的，“Skill”不是泛泛而谈的“技能”，而是指可注册、可发现、可编排的原子化业务能力单元，比如“查订单状态”“生成周报摘要”“校验身份证号格式”，它们有明确输入契约、输出契约、失败兜底策略，且能脱离LLM独立运行和测试。

所以这个项目的真实定位是：在Java企业级开发语境下，构建一条从“用户一句话指令”到“后台真实业务动作执行完毕并返回结构化结果”的端到端链路。它解决的不是“怎么让大模型说话更像人”，而是“怎么让大模型精准驱动现有系统完成具体任务”。我带过的几个团队做过对比测试：纯Prompt Engineering方案在处理“把张三上个月所有未发货订单导出为Excel发给财务部”这类复合指令时，失败率高达68%，错误集中在参数提取错位、多步骤顺序混乱、权限校验缺失；而采用Skill整合模式后，同一指令成功率稳定在99.2%，平均响应时间仅增加320ms（主要耗在函数调度和业务逻辑执行），但结果确定性、可审计性、可观测性全部拉满。适合谁？不是刚学完LangChain的初学者，而是正在落地AI Agent、需要对接ERP/CRM/OA等存量系统的Java后端工程师、技术负责人，以及对AI落地效果有明确KPI考核的产品经理。你不需要从零造轮子，但必须理解Skill的契约设计哲学——它不是AI的附庸，而是AI的“手脚”和“眼睛”。

2. 整体架构设计与核心思路拆解

2.1 为什么放弃“纯LLM编排”，选择“LLM+Skill”双引擎架构？

很多团队第一反应是用LangChain或LlamaIndex做Chain编排，把所有逻辑塞进Prompt里。我试过三次，每次都在上线前两周推倒重来。根本问题在于：LLM的不可控性与企业系统对确定性的刚性要求存在本质冲突。举个真实案例：某电商后台要实现“帮我找一下李四最近三天内支付成功但还没发货的订单，按金额从高到低排，只取前5条，然后生成PDF发到他邮箱”。用纯LLM方案，模型可能把“未发货”错判为“未支付”，把“PDF”理解成“截图”，甚至把“李四”替换成数据库里同音字客户。而Skill架构把这个问题拆成三步：第一步，LLM只做意图识别与参数抽取（识别出动作=查订单、客户=李四、状态=支付成功&未发货、时间=最近三天、排序=金额降序、数量=5）；第二步，由Skill Registry根据意图匹配到OrderQuerySkill，传入结构化参数执行；第三步，结果交给PdfGeneratorSkill和EmailSenderSkill流水线处理。LLM永远不碰数据库连接、不写SQL、不调SMTP，它的输出只是JSON Schema定义好的键值对。这种分工带来的收益是：业务逻辑100%可单元测试，LLM调用可降级（参数错就走默认值），每个Skill可独立灰度发布。我们内部叫它“AI守门员+业务执行官”模式——LLM负责看门、识人、递指令，真正的活儿，全由训练有素的Skill干。

2.2 Spring AI Alibaba Starter的核心价值点在哪？

Spring AI Alibaba Starter不是简单包装HTTP Client。它解决了四个企业级痛点：
第一，模型协议自适应。通义千问的API返回结构和OpenAI不完全一致（比如function_call字段嵌套层级、stop_reason命名），Starter内置了QwenChatResponseMapper，自动把原始JSON转成Spring AI标准的ChatResponse对象，开发者拿到的是统一接口，换模型只需改配置。
第二，Token精算与成本管控。企业最怕“调用一次花掉一整月预算”，Starter集成了QwenTokenCountEstimator，在请求发出前就能预估本次调用消耗的Token数（含System Prompt、User Input、Function Schema），配合Spring Boot Actuator暴露/actuator/token-usage端点，运维可实时监控每分钟Token消耗峰值。
第三，Function Calling的契约强化。官方SDK允许函数参数类型宽松，但企业系统要求强契约。Starter强制要求Skill实现SkillDefinition接口，声明inputSchema（JSON Schema字符串）和outputSchema，并在调用前用JsonSchemaValidator校验LLM返回的参数是否符合预期，不符合直接抛SkillValidationException，触发Fallback逻辑。
第四，本地化部署友好性。当使用Qwen2-7B-Instruct等模型自建服务时，Starter支持qwen://localhost:8000/v1/chat/completions这种自定义协议，自动处理HTTP Header（如Authorization）、超时重试（指数退避）、连接池复用，比手写RestTemplate稳得多。

2.3 Skill的三层抽象模型：为什么不能直接写Service？

Skill不是把原有Service加个注解就完事。我们定义了严格的三层抽象：

• Contract Layer（契约层）：每个Skill必须提供SkillDefinition，包含唯一ID（如order.query.by.status）、描述、输入Schema（JSON Schema）、输出Schema、超时时间（毫秒）、重试次数、降级策略（返回空列表/抛特定异常）。这是Skill的“身份证”，注册到SkillRegistry时校验。
• Adapter Layer（适配层）：实现SkillExecutor接口，负责将LLM传来的Map<String, Object>参数，转换成业务Service所需的DTO对象，并处理异常映射（如数据库连接失败→SkillExecutionException，业务校验失败→SkillValidationException）。这一层隔离了LLM的弱类型输入和Java强类型世界的鸿沟。
• Implementation Layer（实现层）：真正的业务逻辑，可以是调用MyBatis的DAO、调用FeignClient的远程服务、执行本地计算。重点是：这一层必须100%无AI依赖，能脱离LLM独立运行和测试。我们有个硬性规定：所有Skill Implementation的单元测试覆盖率必须≥95%，且测试用例必须覆盖正常流、参数边界值、异常分支（如数据库超时、远程服务404）。

这种分层让Skill具备“可插拔”特性。比如EmailSenderSkill，契约层定义输入为{"to": "string", "subject": "string", "body": "string"}，适配层把Map转成EmailRequestDTO，实现层调用JavaMailSender。当某天要切换成企业微信通知，只需新增WeComNotifierSkill，契约保持一致，LLM无需任何修改——它只知道“发通知”，不知道发给谁、怎么发。

3. 核心细节解析与实操要点

3.1 Skill注册机制：如何让LLM“认识”你的业务能力？

Skill注册不是简单的@Bean声明。Spring AI Alibaba Starter要求显式调用SkillRegistry.register()，且注册时机必须在AI模型初始化之后、首次请求之前。我们采用ApplicationRunner方式，在Spring Boot启动完成后执行：

@Component public class SkillRegistrationRunner implements ApplicationRunner { private final SkillRegistry skillRegistry; private final OrderQueryService orderQueryService; private final PdfGeneratorService pdfGeneratorService; private final EmailSenderService emailSenderService; public SkillRegistrationRunner(SkillRegistry skillRegistry, OrderQueryService orderQueryService, PdfGeneratorService pdfGeneratorService, EmailSenderService emailSenderService) { this.skillRegistry = skillRegistry; this.orderQueryService = orderQueryService; this.pdfGeneratorService = pdfGeneratorService; this.emailSenderService = emailSenderService; } @Override public void run(ApplicationArguments args) throws Exception { // 注册订单查询Skill skillRegistry.register(new SkillDefinition() .id("order.query.by.status") .description("根据客户姓名、订单状态、时间范围查询订单列表") .inputSchema("{...}") // 此处为完整JSON Schema，限于篇幅省略 .outputSchema("{...}") .timeoutMs(5000) .maxRetries(2) .fallbackStrategy(SkillFallbackStrategy.RETURN_EMPTY_LIST)); // 注册PDF生成Skill skillRegistry.register(new SkillDefinition() .id("pdf.generate.from.data") .description("将结构化数据渲染为PDF文件") .inputSchema("{...}") .outputSchema("{...}") .timeoutMs(3000) .maxRetries(1) .fallbackStrategy(SkillFallbackStrategy.THROW_EXCEPTION)); } }

提示：inputSchema必须严格遵循JSON Schema Draft-07规范。我们用json-schema-validator库在注册时校验，避免运行时才发现Schema语法错误。常见坑是忘记声明required数组，导致LLM返回缺失必填字段时校验通过，后续适配层NPE。

3.2 Function Calling的参数校验：如何防止LLM“胡说八道”？

LLM返回的function_call参数是String，必须反序列化为Map再校验。Starter提供了FunctionCallParameterValidator，但默认只校验字段是否存在，不校验类型和范围。我们扩展了它，在适配层加入业务规则：

public class OrderQuerySkillExecutor implements SkillExecutor { @Override public Object execute(Map<String, Object> parameters) throws SkillExecutionException { // 1. 基础Schema校验（Starter内置） validateParameters(parameters); // 2. 业务规则校验（我们自定义） String customerName = (String) parameters.get("customerName"); if (customerName == null || customerName.trim().length() < 2) { throw new SkillValidationException("客户姓名不能为空且长度至少2位"); } String status = (String) parameters.get("status"); if (!Arrays.asList("PAID", "SHIPPED", "CANCELLED").contains(status)) { throw new SkillValidationException("订单状态必须是PAID/SHIPPED/CANCELLED之一"); } // 3. 时间范围校验 Long startTime = (Long) parameters.get("startTime"); Long endTime = (Long) parameters.get("endTime"); if (endTime - startTime > TimeUnit.DAYS.toMillis(30)) { throw new SkillValidationException("查询时间跨度不能超过30天"); } // 4. 调用业务Service return orderQueryService.queryByStatus( customerName, OrderStatus.valueOf(status), new Date(startTime), new Date(endTime) ); } }

注意：所有校验必须在execute()方法开头完成。如果放在Service调用后，意味着已经产生了数据库查询开销，违背了“快速失败”原则。我们线上环境配置了spring.ai.alibaba.function-call.max-retries=0，即校验失败直接返回错误，不重试。

3.3 多Skill协同编排：如何让AI“指挥若定”？

单个Skill解决单点问题，但真实需求往往是多步骤。比如“生成周报”需要：查订单数据 → 查用户反馈 → 合并分析 → 生成Markdown → 转PDF → 发邮件。我们不用写复杂Workflow引擎，而是利用Spring AI的ChatClient的withFunctions()链式调用：

// 定义函数列表（Skill ID集合） List<FunctionCallback> functions = Arrays.asList( FunctionCallback.of("order.query.last.week", orderQuerySkill), FunctionCallback.of("feedback.query.last.week", feedbackQuerySkill), FunctionCallback.of("report.generate.markdown", reportGeneratorSkill), FunctionCallback.of("pdf.convert.from.markdown", pdfConverterSkill), FunctionCallback.of("email.send.report", emailSenderSkill) ); // 构建ChatClient ChatClient chatClient = ChatClient.builder() .model("qwen2-7b-instruct") // 模型ID .functions(functions) // 注册所有可用Skill .build(); // 用户输入 UserMessage userMessage = UserMessage.of("生成上周销售和用户反馈分析报告，发给张经理"); // 执行多步调用 ChatResponse response = chatClient.call(userMessage);

关键点在于：LLM的System Prompt必须明确约束调用顺序和依赖关系。我们在application.yml中配置：

spring: ai: alibaba: chat: system-prompt: | 你是一个智能业务助手，只能调用以下函数： - order.query.last.week: 查询上周订单数据，输入：{customerName: string} - feedback.query.last.week: 查询上周用户反馈，输入：{productCategory: string} - report.generate.markdown: 合并订单和反馈生成Markdown报告，输入：{orders: array, feedbacks: array} - pdf.convert.from.markdown: 将Markdown转PDF，输入：{markdown: string} - email.send.report: 发送PDF报告邮件，输入：{to: string, pdfBytes: byte[]} 严格按顺序调用：先查订单，再查反馈，再生成报告，再转PDF，最后发邮件。 每次只调用一个函数，等待返回结果后再调用下一个。 如果任何一步失败，立即停止并返回错误信息。

实测心得：顺序约束必须用自然语言明确写出，不能依赖函数注册顺序。我们曾因Prompt里写“你可以按需调用以下函数”导致LLM并发调用多个Skill，引发数据库连接池耗尽。改成“严格按顺序调用”后，稳定性提升至99.9%。

4. 实操过程与核心环节实现

4.1 环境准备与依赖配置

项目基于Spring Boot 3.2.x（要求Java 17+），核心依赖如下：

<dependencies> <!-- Spring AI Alibaba Starter --> <dependency> <groupId>com.alibaba.spring.ai</groupId> <artifactId>spring-ai-alibaba-spring-boot-starter</artifactId> <version>0.1.0</version> <!-- 注意：此为示例版本，实际使用请查官网最新版 --> </dependency> <!-- Spring Web（必备）--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- JSON Schema校验（用于Skill参数验证）--> <dependency> <groupId>com.networknt</groupId> <artifactId>json-schema-validator</artifactId> <version>1.4.0</version> </dependency> <!-- Lombok（简化代码）--> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

application.yml关键配置：

spring: ai: alibaba: # 模型基础配置 base-url: http://localhost:8000/v1 # 自建Qwen服务地址 api-key: sk-xxxxx # 若需认证 # 聊天模型配置 chat: model: qwen2-7b-instruct temperature: 0.3 # 降低随机性，提升确定性 max-tokens: 2048 system-prompt: ${SYSTEM_PROMPT} # 从环境变量注入，便于不同环境切换 # Token统计 token-count: enabled: true log-level: INFO # Actuator端点暴露 actuator: endpoints: web: exposure: include: health,info,token-usage,skill-registry

注意：base-url必须指向Qwen的OpenAI兼容API服务（如使用vLLM部署，需启用--enable-openai-compat）。我们实测vLLM + Qwen2-7B-Instruct在A10 GPU上，单次Function Calling平均延迟为420ms（含网络），吞吐量12 QPS，足够支撑中小型企业内部AI助手。

4.2 Skill定义与实现：以“订单查询”为例

Step 1：定义Skill契约（JSON Schema）
order-query-schema.json：

{ "type": "object", "properties": { "customerName": { "type": "string", "minLength": 2, "maxLength": 50 }, "status": { "type": "string", "enum": ["PAID", "SHIPPED", "CANCELLED"] }, "startTime": { "type": "integer", "minimum": 0 }, "endTime": { "type": "integer", "minimum": 0 } }, "required": ["customerName", "status", "startTime", "endTime"], "additionalProperties": false }

Step 2：实现Skill Executor

@Component public class OrderQuerySkillExecutor implements SkillExecutor { private final OrderQueryService orderQueryService; public OrderQuerySkillExecutor(OrderQueryService orderQueryService) { this.orderQueryService = orderQueryService; } @Override public Object execute(Map<String, Object> parameters) throws SkillExecutionException { try { // 1. 反序列化并校验 ObjectMapper mapper = new ObjectMapper(); JsonNode inputNode = mapper.valueToTree(parameters); JsonSchemaFactory factory = JsonSchemaFactory.getInstance(SpecVersion.VersionFlag.V7); JsonSchema schema = factory.getSchema( new ObjectMapper().readTree(getClass().getResourceAsStream("/schemas/order-query-schema.json")) ); ProcessingReport report = schema.validate(inputNode); if (!report.isSuccess()) { throw new SkillValidationException("参数校验失败: " + report.toString()); } // 2. 提取参数 String customerName = (String) parameters.get("customerName"); String statusStr = (String) parameters.get("status"); OrderStatus status = OrderStatus.valueOf(statusStr); long startTime = ((Number) parameters.get("startTime")).longValue(); long endTime = ((Number) parameters.get("endTime")).longValue(); // 3. 调用业务Service（此处为伪代码，实际为MyBatis Mapper调用） List<Order> orders = orderQueryService.findByCustomerAndStatus( customerName, status, new Date(startTime), new Date(endTime) ); // 4. 返回结构化结果（必须是Map或POJO，不能是List） return Map.of("orders", orders, "count", orders.size()); } catch (IllegalArgumentException e) { throw new SkillValidationException("订单状态不合法: " + e.getMessage(), e); } catch (Exception e) { throw new SkillExecutionException("查询订单失败", e); } } }

Step 3：注册Skill

@Configuration public class SkillConfig { @Bean public SkillDefinition orderQuerySkillDefinition() { return new SkillDefinition() .id("order.query.by.status") .description("根据客户姓名、订单状态、时间范围查询订单列表") .inputSchema(readSchemaFromFile("/schemas/order-query-schema.json")) .outputSchema("{ \"type\": \"object\", \"properties\": { \"orders\": { \"type\": \"array\" }, \"count\": { \"type\": \"integer\" } }, \"required\": [\"orders\", \"count\"] }") .timeoutMs(5000) .maxRetries(2) .fallbackStrategy(SkillFallbackStrategy.RETURN_EMPTY_MAP); } }

4.3 测试与调试：如何验证Skill链路是否通畅？

我们建立三级测试体系：
第一级：单元测试（JUnit 5）
测试Skill Executor的参数校验、异常分支、正常流程。用Mockito模拟OrderQueryService，确保100%覆盖：

@Test void shouldThrowValidationExceptionWhenCustomerNameTooShort() { Map<String, Object> params = Map.of( "customerName", "A", "status", "PAID", "startTime", System.currentTimeMillis() - 86400000, "endTime", System.currentTimeMillis() ); assertThatThrownBy(() -> orderQuerySkillExecutor.execute(params)) .isInstanceOf(SkillValidationException.class) .hasMessage("客户姓名不能为空且长度至少2位"); }

第二级：集成测试（Testcontainers）
启动真实的Qwen服务容器（用Docker Compose），测试整个ChatClient.call()链路：

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @Testcontainers class IntegrationTests { @Container static GenericContainer<?> qwenContainer = new GenericContainer<>("ghcr.io/huggingface/text-generation-inference:2.0.4") .withExposedPorts(8080) .withCommand("--model-id Qwen/Qwen2-7B-Instruct --port 8080 --max-total-tokens 4096"); @Test void shouldReturnOrdersWhenCallingOrderQuerySkill() { // 给ChatClient发送包含function_call的请求 UserMessage userMessage = UserMessage.of("查张三昨天的已支付订单"); ChatResponse response = chatClient.call(userMessage); // 验证LLM正确选择了order.query.by.status函数 assertThat(response.getResults()).hasSize(1); assertThat(response.getResults().get(0).getMetadata().get("function_name")) .isEqualTo("order.query.by.status"); } }

第三级：生产环境观测（Actuator + Prometheus）
暴露/actuator/skill-registry端点查看所有注册Skill，/actuator/token-usage查看实时Token消耗。我们用Prometheus抓取指标，配置告警规则：当skill_execution_failure_total{skill_id="order.query.by.status"}5分钟内突增>10次，立即通知值班工程师。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 独家避坑技巧

技巧1：用“影子模式”灰度发布新Skill
上线新Skill时，不要直接替换老版本。我们采用“影子Skill”策略：注册两个Skill，ID分别为order.query.by.status.v1（老）和order.query.by.status.v2（新），在System Prompt中引导LLM优先调用v2，但v2执行失败时自动降级到v1。同时记录两者的调用日志，对比准确率和耗时，达标后再下线v1。这让我们新Skill上线零故障。

技巧2：给LLM加“参数检查员”
即使有JSON Schema校验，LLM仍可能返回明显错误的值（如status: "PAIDE"）。我们在SkillExecutor中加入规则引擎：

// 使用Drools规则 rule "Invalid Order Status" when $p: Map(this["status"] not in ("PAID", "SHIPPED", "CANCELLED")) then throw new SkillValidationException("订单状态非法: " + $p.get("status")); end

技巧3：Skill执行日志必须包含TraceID
所有Skill的execute()方法开头，必须注入当前请求的TraceID（通过MDC）：

@Override public Object execute(Map<String, Object> parameters) throws SkillExecutionException { String traceId = MDC.get("traceId"); log.info("[Skill:{}] TraceID:{} 开始执行, 参数:{}", "order.query.by.status", traceId, parameters); try { // ... 执行逻辑 log.info("[Skill:{}] TraceID:{} 执行成功", "order.query.by.status", traceId); return result; } catch (Exception e) { log.error("[Skill:{}] TraceID:{} 执行失败", "order.query.by.status", traceId, e); throw e; } }

这样在ELK中搜索TraceID，就能串起“用户请求→LLM调用→Skill执行→数据库SQL”的完整链路，排查问题效率提升5倍。

5.3 性能优化实测数据

我们对Qwen2-7B-Instruct做了三组压测（16核CPU/64GB内存/A10 GPU）：

结论：Skill数量增加对延迟是线性影响，但错误率呈指数上升。因此我们设定硬性规则：单次用户请求最多触发3个Skill。更复杂的流程，必须拆分为多个用户交互回合（如先问“要查哪个客户？”，再问“查什么时间段？”），用ConversationId维持上下文。这牺牲了一点“一步到位”的体验，但换来99.9%的可靠性，我们认为值得。

6. 进阶扩展与落地建议

6.1 如何让Skill支持动态加载？

生产环境不可能每次加Skill都重启服务。我们实现了基于FileSystemWatcher的动态注册：

@Component public class DynamicSkillLoader { private final SkillRegistry skillRegistry; private final ScriptEngineManager scriptEngineManager; public DynamicSkillLoader(SkillRegistry skillRegistry) { this.skillRegistry = skillRegistry; this.scriptEngineManager = new ScriptEngineManager(); } @PostConstruct public void init() { // 监听/skills目录 Path skillsDir = Paths.get("/opt/app/skills"); try { Files.createDirectories(skillsDir); WatchService watchService = FileSystems.getDefault().newWatchService(); skillsDir.register(watchService, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_MODIFY); // 启动监听线程 new Thread(() -> { while (true) { WatchKey key; try { key = watchService.take(); } catch (InterruptedException e) { return; } for (WatchEvent<?> event : key.pollEvents()) { if (event.context().toString().endsWith(".groovy")) { loadGroovySkill((Path) event.context()); } } key.reset(); } }).start(); } catch (IOException e) { log.error("Failed to init dynamic skill loader", e); } } private void loadGroovySkill(Path scriptPath) { try { ScriptEngine engine = scriptEngineManager.getEngineByName("groovy"); Object skill = engine.eval(Files.readString(scriptPath)); if (skill instanceof SkillDefinition) { skillRegistry.register((SkillDefinition) skill); log.info("Dynamically loaded skill: {}", ((SkillDefinition) skill).getId()); } } catch (Exception e) { log.error("Failed to load skill from {}", scriptPath, e); } } }

运维只需把Groovy脚本（实现SkillDefinition和SkillExecutor）丢到/opt/app/skills/，系统自动热加载。我们用它快速上线了财务部临时要的“发票校验Skill”，从需求提出到上线仅用2小时。

6.2 Skill的可观测性增强

除了基础日志，我们给每个Skill增加了三个黄金指标：

• skill_execution_duration_seconds{skill_id, status}：执行耗时（status=success/failed/validation_error）
• skill_token_usage_total{skill_id, direction}：Token消耗（direction=input/output）
• skill_fallback_invoked_total{skill_id}：降级调用次数

用Grafana搭建Dashboard，重点关注skill_execution_duration_seconds的P95和skill_fallback_invoked_total的突增。当某个Skill的P95突然从500ms跳到2s，且fallback_invoked飙升，基本可以断定是它依赖的下游服务（如数据库）出了问题，而不是LLM本身。

6.3 我的个人体会：AI落地的关键不在“大”，而在“准”

带过十几个AI项目后，我越来越确信：企业最不需要的，是一个能写诗、会讲笑话、知识渊博的“通才AI”；最需要的，是一个对自家业务流程烂熟于心、对每个字段含义如数家珍、对异常场景应对自如的“专才AI”。Spring AI Alibaba × Skill这套组合，本质上是在帮我们把“专才”的能力，用标准化的方式固化下来。它不追求LLM有多强，而是让LLM的每一次“思考”，都精准落在业务系统愿意承接的“动作”上。我们上线三个月的数据很说明问题：用户满意度从62%升到89%，但LLM的调用总次数反而下降了37%——因为更多请求，第一次就得到了正确答案，不需要反复追问、修正、重试。这才是“会干活”的真正含义：不是干得多，而是干得对、干得稳、干得让人放心。