企业官网建设流程全解析

1. 项目概述：当Agent从“魔法咒语”变成可拆解的机械钟表

“告别‘黑盒神话’：主流 Agent 框架的工程反思与‘物理外化’范式的崛起”——这个标题里藏着过去两年我在十几个真实Agent项目里踩出来的血泪经验。不是在实验室调参，也不是写个Demo发到GitHub上收获几个Star，而是给银行做智能投顾中台、给制造业客户搭设备故障推理引擎、给政务系统做政策问答聚合平台时，被生产环境反复暴打后总结出的一套“反直觉”方法论。

核心关键词“Agent”“框架”“工程”“物理外化”“范式”，不是空泛概念堆砌。它直指一个现实矛盾：我们用LangChain写完一个能调用天气API、查股票、再写邮件的Agent Demo，花3小时；但把它部署进日均50万请求、要求99.95%可用率、审计日志必须留存18个月、上下游全是Java老系统的企业级环境，却花了67天，其中42天卡在“为什么这个链路在压测时延迟突增300ms”“为什么重试三次后记忆状态就错乱”“为什么审计日志里看不到某次工具调用的真实入参”这类问题上。所谓“黑盒神话”，就是把Agent当成一个输入提示词、输出答案的魔法盒子，而忘了它本质上是一段运行在Linux进程里的、会读写数据库、会发HTTP请求、会竞争线程锁、会因GC暂停的物理存在。

“物理外化”不是玄学术语，它是我给团队定下的铁律：任何抽象层（Planning、Memory、Tool Calling）都必须有对应、可观测、可干预的物理载体。Planning不能只是一段LLM生成的JSON字符串，它必须落地为数据库里一条带trace_id、status、start_time、plan_steps字段的记录；Memory不能只是嵌在向量库里的模糊匹配结果，它必须是Redis里以session_id为key、带TTL和版本号的哈希结构；Tool Calling不能依赖框架自动序列化，每次调用前必须写入Kafka Topic，包含原始参数、序列化后参数、调用方IP、超时设置等完整上下文。这不是过度设计，而是让Agent从“不可调试的AI行为”回归到“可监控、可回滚、可审计的软件工程实体”。

适合谁看？如果你正面临这些场景：用LangChain或LlamaIndex搭的Agent在本地跑得飞起，一上预发就报ConnectionResetError；你团队的SRE说“这个服务没有健康检查端点，我们没法加到巡检体系里”；产品经理问“用户上次问‘我的订单为什么没发货’，系统到底查了哪几个接口、用了哪些历史对话”，你答不上来；或者你刚看完吴恩达的Agent教程，兴奋地写了200行代码，却发现连最基础的并发请求下状态隔离都做不到——那么这篇内容就是为你写的。它不教你怎么写第一个Hello World Agent，而是告诉你，当那个Hello World要扛住真实世界的风沙雨雪时，你该拧紧哪几颗螺丝。

2. 主流Agent框架的工程短板：不是功能缺失，而是物理锚点缺位

2.1 LangChain：优雅的抽象，脆弱的落地

LangChain无疑是Agent开发的启蒙者，它的Chain、AgentExecutor、Tool抽象让开发者第一次感受到“编排智能”的快感。但深入工程一线，你会发现它的设计哲学与企业级运维需求存在根本性错位。最典型的例子是Memory管理。

LangChain的ConversationBufferMemory、ConversationSummaryMemory等，本质是Python对象内的列表或LLM调用。问题来了：当你的服务是基于Spring Boot构建的微服务集群，每个实例都持有一个独立的Memory对象，用户A在实例1发起对话，实例2处理后续请求时，Memory就是空的。LangChain官方文档建议“用RedisBackend”，但实际接入时，你得自己实现load_memory_variables和save_context方法，而这两个方法的签名（input: Dict, output: Dict）完全不暴露原始消息序列、时间戳、session_id来源。我见过最惨的案例：某金融客户要求所有对话必须留存原始消息（含用户脱敏ID、时间、渠道），但LangChain的Memory save逻辑会把input字典里的content字段二次JSON序列化，导致审计日志里看到的是{"content": "{\"user_id\": \"u_123\", \"text\": \"查余额\"}"}——这根本无法满足合规要求。

更隐蔽的坑在Tool执行链路。LangChain的Tool定义只要求name、description、func，但生产环境需要的远不止于此。你需要知道：这个Tool调用是否计入SLA统计？失败时是否触发告警？重试策略是指数退避还是固定间隔？参数是否需要脱敏？LangChain不提供这些钩子。我们被迫在每个Tool函数外层硬套一层装饰器，手动记录tool_name、start_ts、end_ts、status、error_type、masked_params，然后统一上报到ELK。这相当于用胶带把一辆法拉利绑在拖拉机上——不是车不行，是设计时就没考虑过拖拉机的底盘。

提示：LangChain的CallbackHandler看似是解药，但它是个“事后诸葛亮”。on_tool_start能拿到参数，但on_tool_end只能拿到结果，中间如果Tool内部发生网络超时、重试、熔断，CallbackHandler根本收不到事件。真正的工程可观测性，需要在Tool调用发起的第一毫秒就埋点，而不是等它结束。

2.2 LlamaIndex：检索即正义，但检索之外皆混沌

LlamaIndex的核心优势在于RAG（检索增强生成），它的VectorStoreIndex、QueryEngine封装了向量检索的复杂性。然而，当它被嵌入Agent框架时，“检索”之外的环节立刻暴露短板。典型场景：用户问“上季度华东区销售额最高的三个产品是什么”，Agent需要先理解意图（识别“上季度”“华东区”“销售额”“TOP3”），再构造检索Query，最后解析LLM返回的表格数据。

LlamaIndex的RetrieverQueryEngine只负责“检索-重排-生成”这一条线，但意图识别和结果解析这两头，它完全不管。我们曾用llama_index.core.query_engine.SubQuestionQueryEngine拆解复合问题，结果发现它生成的子问题（如“华东区有哪些城市？”“各城市上季度销售额是多少？”）直接喂给LLM，而LLM返回的JSON格式千奇百怪——有时是{"cities": ["上海", "杭州"]}，有时是{"result": [{"city": "上海", "sales": 1200000}]}。没有Schema校验，没有类型转换，没有错误降级（比如当LLM返回非JSON时，是抛异常还是返回空列表？）。最终，我们不得不在QueryEngine外再包一层ResultSanitizer，用Pydantic模型强制校验，失败时降级为调用预置SQL模板。

另一个致命伤是状态持久化粒度太粗。LlamaIndex的StorageContext支持把索引存到磁盘或S3，但这是“全量索引”的持久化。而生产环境需要的是“增量更新”：每天凌晨同步ERP新订单数据，只更新涉及产品的向量，而不是重建整个索引。LlamaIndex原生不支持Partial Index Update，我们只能自己实现DeltaVectorStore，监听数据库binlog，提取变更的product_id，调用index.insert_nodes()单条插入，并维护一个last_updated_at时间戳用于增量同步。这已经超出了LlamaIndex的设计范畴，变成了在它的抽象层上打补丁。

2.3 自研框架的幻觉：以为“可控”就等于“可靠”

不少技术负责人看到LangChain/LlamaIndex的缺陷后，会拍板“我们自研Agent框架”。我参与过两个这样的项目，结局惊人一致：6个月后，框架代码量达到3万行，核心模块包括PlanScheduler、MemoryOrchestrator、ToolRegistry，但上线首月就因PlanScheduler的Quartz定时任务与ToolRegistry的Spring Bean生命周期冲突，导致计划任务漏执行；第二个月，MemoryOrchestrator在高并发下因Redis连接池耗尽，引发雪崩。问题根源在于：自研框架往往只解决了“我想怎么编排”，却忽略了“系统怎么稳定运行”。

比如ToolRegistry，理想中它应该像Spring的@Bean一样自动注册，但生产环境要求每个Tool必须配置timeout_ms=3000、retry_times=2、circuit_breaker_enabled=true。如果把这些配置硬编码在@Tool注解里，那ToolRegistry就得解析Java字节码——这违背了Spring Boot的约定优于配置原则。我们最终方案是：放弃注解驱动，改用YAML配置文件，ToolRegistry启动时读取tools.yml，动态注册Bean，并将配置注入到ToolExecutor中。这看起来笨重，但它让SRE能直接修改YAML重启服务，而不用等Java工程师发版。

注意：所有“框架级”的抽象，一旦脱离了具体物理载体（进程、线程、内存、网络、磁盘），就必然在工程落地时付出代价。LangChain的“Chain”抽象很美，但它没告诉你，当一个Chain包含5个LLM调用+3个HTTP请求时，它的P99延迟由哪个环节决定？是第一个LLM的GPU显存不足，还是第三个HTTP请求的DNS解析慢？没有物理锚点，你就永远在猜。

3. “物理外化”范式：把每个抽象概念钉死在真实的硬件/软件资源上

3.1 Planning的物理化：从LLM输出到数据库事务

Planning在Agent中常被描述为“思考下一步做什么”，但在工程视角，它必须是一个可原子提交、可幂等重放、可跨服务追踪的操作。我们摒弃了“LLM生成JSON Plan”的做法，转而采用“Plan as Transaction”模式。

具体实现：

1. 用户请求到达网关，生成全局唯一request_id（如req_20240520_abc123）；
2. PlanService收到请求，不调用LLM，而是根据预设规则引擎（Drools）匹配业务场景，生成标准化Plan模板（如SALES_INQUIRY_PLAN_V1）；
3. 将Plan模板、request_id、当前时间戳、初始上下文（用户ID、渠道、设备指纹）作为一行记录，插入MySQL的agent_plan表，主键为plan_id（自增ID）；
4. 启动一个异步任务，轮询agent_plan表，对status='PENDING'且created_at < NOW()-INTERVAL 1 SECOND的记录，调用LLM填充模板中的占位符（如{top3_products}），更新plan_content字段并置status='READY'；
5. 执行引擎只消费status='READY'的Plan，执行完毕后更新status='COMPLETED'或'FAILED'。

这个设计带来三大工程收益：

• 可观测性：DBA可以直接SELECT * FROM agent_plan WHERE request_id='req_20240520_abc123'，看到Plan的完整生命周期；
• 可追溯性：审计要求“展示用户A在T时刻的决策依据”，直接查plan_content字段，里面是纯文本，无需解析JSON；
• 可恢复性：如果执行引擎宕机，重启后只需继续轮询PENDING/READY状态的Plan，不会丢失任何步骤。

我们曾用此方案支撑某电商大促期间的智能客服，峰值QPS 1200，agent_plan表单日写入2亿行，通过分库分表（按request_id哈希）和冷热分离（7天内热数据在SSD，旧数据归档至OSS），保障了Plan生成延迟稳定在80ms内。

3.2 Memory的物理化：从向量相似度到带版本的Key-Value存储

传统RAG的Memory依赖向量库的近似最近邻（ANN）搜索，但ANN的结果是概率性的，无法保证“相同输入必得相同输出”。工程上，我们需要确定性。

我们的方案是：Memory = Session ID + Versioned Key-Value + TTL。

• Session ID由网关统一分配，格式为sess_{user_id}_{channel}_{timestamp}（如sess_u123_web_1716201600），确保同一用户同渠道会话的连续性；
• 所有Memory操作（读/写/删）都路由到Redis Cluster的一个特定DB（如DB 8），Key为mem:{sess_id}:{version}，Value为JSON字符串，包含messages数组、summary字段、last_accessed_at时间戳；
• 每次写入Memory，都生成新Version（如v1、v2），旧Version保留（用于回滚），同时更新mem:{sess_id}:current指向最新Version；
• TTL设为30分钟，但每次读取时，通过EXPIRE命令重置TTL，实现“活跃会话永不过期，静默会话自动清理”。

关键创新点在于Summary的物理化。我们不用LLM实时生成Summary，而是在每次写入新Message后，触发一个轻量级Python Worker（用Celery调度），用规则引擎提取关键信息：

• 如果Message含订单号（正则\bORD\d{8}\b），则Summary追加"orders": ["ORD12345678"]；
• 如果Message含时间范围（如“上个月”），则计算start_date/end_date并存入"date_range"；
• 最终Summary是结构化JSON，可直接被下游服务（如风控系统）消费。

这避免了每次Query都调用LLM做Summary，将Summary生成延迟从1.2s降至20ms，同时保证了Summary字段的强一致性。

3.3 Tool Calling的物理化：从函数调用到Kafka事件总线

Tool Calling是Agent最易失控的环节。LangChain的tool.func(input)调用，一旦func内部发生网络超时、重试、熔断，上层Agent Executor可能还在等待，导致整个Chain阻塞。

我们的解法是：Tool Calling = Kafka Producer + Consumer + Dead Letter Queue。

• 当Agent决定调用Tool A时，ToolDispatcher服务向Kafka Topictool_call_requests发送一条消息，内容为：

{ "tool_name": "get_stock_price", "params": {"symbol": "AAPL"}, "timeout_ms": 5000, "retry_times": 2, "trace_id": "trc_20240520_abc123", "callback_url": "http://agent-executor/callback" }

• 独立的ToolWorker服务（Go编写）消费此Topic，执行实际HTTP调用，成功后向tool_call_resultsTopic发结果，失败则发错误消息到tool_call_errors；
• ToolDispatcher通过callback_url接收结果，更新本地状态；
• 所有tool_call_*Topic都启用Kafka Exactly-Once语义，确保不丢不重。

这套设计的价值在于：

• 解耦：Agent Executor不再关心Tool的实现细节，只管发消息；
• 弹性：ToolWorker可水平扩展，应对不同Tool的负载差异（如天气API QPS低但延迟敏感，数据库查询QPS高但可容忍延迟）；
• 可观测性：Kafka Manager可实时查看各Topic积压量，tool_call_errors里的错误类型（TIMEOUT、HTTP_503、VALIDATION_ERROR）一目了然；
• 治理：通过Kafka ACL，可限制ToolWorker只能读tool_call_requests，只能写tool_call_results，杜绝越权。

我们曾用此架构支撑某物流公司的运单轨迹查询Agent，日均Tool调用量800万次，tool_call_requestsTopic峰值积压<100条，P99延迟<150ms。

4. 工程实践全景：从零搭建一个“物理外化”Agent系统的实操步骤

4.1 环境准备与技术栈选型：为什么是Spring Boot而非FastAPI？

选型不是比谁新，而是比谁稳、谁生态全、谁运维熟。我们最终选定：

• 后端框架：Spring Boot 3.2（JDK 17）——理由：公司已有成熟的Spring Cloud Alibaba微服务治理体系（Nacos注册中心、Sentinel限流、Seata分布式事务），Agent服务必须无缝融入；
• 向量库：Milvus 2.4 —— 理由：相比FAISS（单机）和Chroma（轻量但无高可用），Milvus支持分布式部署、多副本、自动扩缩容，且提供SQL-like查询语法，便于DBA管理；
• 消息队列：Apache Kafka 3.5 —— 理由：金融级可靠性（ISR机制）、精确一次语义、强大的监控生态（Burrow、Kafka Manager）；
• 缓存：Redis 7.2 Cluster —— 理由：原生Cluster模式，支持水平扩展，RedisJSON模块可直接操作JSON字段，省去序列化开销；
• 数据库：MySQL 8.0（InnoDB）—— 理由：ACID事务保障Plan状态一致性，DBA团队经验丰富。

实操心得：别迷信“云原生”就一定要用K8s。我们初期将Agent服务部署在阿里云ECS（CentOS 7）上，用Supervisor管理进程，用Prometheus+Grafana监控。直到QPS稳定在500以上、且出现跨AZ容灾需求时，才迁移到K8s。过早容器化会把精力消耗在YAML调试上，而非业务逻辑打磨。

4.2 核心模块编码：PlanService的事务边界与异常处理

PlanService是物理外化范式的入口，其代码必须体现“事务优先”原则。以下是关键片段（Spring Boot Java）：

@Service public class PlanService { @Autowired private JdbcTemplate jdbcTemplate; // 使用原生JDBC，绕过ORM的事务陷阱 @Autowired private KafkaTemplate<String, String> kafkaTemplate; // 此方法必须在事务内执行，确保Plan创建与事件发送原子性 @Transactional(rollbackFor = Exception.class) public Plan createInitialPlan(String requestId, String userId, String channel) { // 1. 插入Plan记录，status='PENDING' String sql = "INSERT INTO agent_plan (request_id, user_id, channel, status, created_at) VALUES (?, ?, ?, 'PENDING', NOW())"; KeyHolder keyHolder = new GeneratedKeyHolder(); jdbcTemplate.update(con -> { PreparedStatement ps = con.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); ps.setString(1, requestId); ps.setString(2, userId); ps.setString(3, channel); return ps; }, keyHolder); Long planId = keyHolder.getKey().longValue(); // 2. 发送Kafka事件，触发LLM填充 PlanEvent event = new PlanEvent(); event.setPlanId(planId); event.setRequestId(requestId); event.setEventType("PLAN_CREATED"); kafkaTemplate.send("plan_events", String.valueOf(planId), JSON.toJSONString(event)); return new Plan(planId, requestId, "PENDING"); } // 异常处理：捕获所有可能中断事务的异常 @ExceptionHandler({DataAccessException.class, SQLException.class}) public ResponseEntity<String> handleDbException(Exception e) { log.error("PlanService DB error", e); return ResponseEntity.status(500).body("Plan creation failed due to database error"); } }

关键点解析：

• 使用JdbcTemplate而非JPA Hibernate，因为Hibernate的二级缓存和延迟加载在高并发下易引发LazyInitializationException，而JDBC直连可控性更强；
• @Transactional标注在createInitialPlan上，确保INSERT和Kafka send在同一个数据库事务内。如果Kafka发送失败（网络抖动），事务回滚，Plan记录不会残留；
• @ExceptionHandler捕获DataAccessException（Spring包装的DB异常）和SQLException（底层异常），避免未捕获异常导致事务不回滚。

我们曾在线上遇到MySQL主从延迟导致SELECT LAST_INSERT_ID()返回0的问题，通过将KeyHolder替换为SimpleJdbcInsert并显式指定主键生成策略，彻底解决。

4.3 部署与监控：让SRE能一眼看懂Agent在干什么

部署不是扔个Docker镜像就完事。我们为Agent服务定义了SRE友好的“四大黄金指标”：

1. Plan生成延迟：从agent_plan表created_at到status='READY'的时间差，P95 < 200ms；
2. Memory命中率：Redis中mem:{sess_id}:currentKey的GET成功率，目标 > 99.9%；
3. Tool调用成功率：Kafkatool_call_resultsTopic消息量 / (tool_call_requests+tool_call_errors)，目标 > 99.5%；
4. LLM Token消耗：每请求平均输入+输出Token数，用于成本审计，阈值设为5000。

监控配置（Prometheus YAML）：

- job_name: 'agent-service' static_configs: - targets: ['agent-service:8080'] metrics_path: '/actuator/prometheus' # 自定义指标：Plan生成延迟 - job_name: 'agent-plan-latency' static_configs: - targets: ['mysql-exporter:9104'] metrics_path: '/probe' params: module: ['mysql'] target: ['mysql-host:3306'] # 查询SQL：SELECT AVG(TIMESTAMPDIFF(MICROSECOND, created_at, updated_at))/1000 AS latency_ms FROM agent_plan WHERE status='READY' AND updated_at > DATE_SUB(NOW(), INTERVAL 1 MINUTE)

Grafana看板包含：

• 实时火焰图（Arthas采集），定位CPU热点（如VectorStoreIndex.query方法）；
• Kafka Topic积压量热力图，按tool_name维度着色；
• Redis Key空间使用率，预警mem:*Key爆炸式增长；
• MySQL慢查询TOP 10，自动关联agent_plan表的plan_id。

注意：所有监控指标必须有明确的业务含义。不要只看“JVM GC时间”，而要看“GC导致Plan生成延迟突增”。我们曾发现G1 GC的Mixed GC阶段会暂停应用200ms，于是将-XX:G1MixedGCCountTarget=8调优为16，将单次Mixed GC时间从200ms降至80ms，Plan P95延迟下降35%。

4.4 压测与调优：如何让Agent扛住2026 FPS级流畅体验

“2026 FPS级流畅”是网络热词，它直指低延迟反射与1% Low帧的工程实践。对Agent而言，FPS即QPS（Queries Per Second），2026 FPS意味着每秒处理2026个用户请求，且99%的请求延迟<100ms，最差的1%（1% Low）延迟<300ms。

我们用JMeter进行阶梯式压测：

• 第一阶段：500 QPS，持续5分钟，观察Plan生成、Tool调用、LLM响应的P95延迟；
• 第二阶段：1000 QPS，引入--ramp-up 300（5分钟爬坡），重点监控MySQL连接池（HikariCP）的ActiveConnections和IdleConnections；
• 第三阶段：2026 QPS，开启--duration 600（10分钟），验证1% Low帧达标率。

压测中暴露的关键瓶颈及解法：

• 瓶颈1：MySQL连接池耗尽
  现象：HikariPool-1 - Connection is not available, request timed out after 30000ms.
  解法：将maximumPoolSize从20调至50，同时增加connection-timeout=3000（3秒），避免长连接阻塞；
• 瓶颈2：Redis连接竞争
  现象：redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
  解法：升级Jedis客户端至4.4.3，启用JedisPoolConfig.setMaxWaitMillis(2000)，并增加maxTotal=200；
• 瓶颈3：LLM API限流
  现象：OpenAI返回429 Too Many Requests，tool_call_errors中rate_limit_exceeded占比飙升。
  解法：在ToolWorker中实现令牌桶算法，为每个tool_name维护独立令牌桶，get_stock_price每秒限100次，weather_forecast限50次，超限请求写入tool_call_throttledTopic，由后台任务异步重试。

最终，我们在2026 QPS下达成：

• Plan生成P95延迟：92ms
• Tool调用P95延迟：145ms
• LLM响应P95延迟：210ms
• 整体端到端P95延迟：288ms（<300ms）
• 1% Low帧（P99延迟）：412ms（略超，通过增加LLM实例数优化至398ms）

5. 常见问题与排查技巧实录：那些只有踩过坑才知道的真相

5.1 问题速查表：高频故障现象、根因与修复命令

5.2 独家避坑技巧：来自血泪教训的3个“一定不要”

一定不要在Agent Executor中做重试逻辑
很多团队在AgentExecutor.run()里写for i in range(3): try: ... except: time.sleep(1)。这是灾难。因为Executor是单线程（或线程池有限），重试会阻塞其他请求。正确做法：将重试交给Kafka，tool_call_errors中的消息带上retry_count字段，Consumer检测到retry_count<3时，延迟1秒后重新发回tool_call_requests。这样重试是异步、非阻塞的。

一定不要用LLM生成的ID作为数据库主键
曾有团队用str(uuid.uuid4())[:8]作为Plan ID，结果线上出现主键冲突（UUID碰撞概率虽低，但QPS高时不可忽视）。我们强制使用MySQL自增ID +request_id组合，plan_id为数字，request_id为字符串索引，既保证唯一性，又利于JOIN查询。

一定不要在Memory中存储原始用户输入
某政务项目要求“用户身份证号必须脱敏”，但开发人员直接把{"id_card": "110101199003072135"}存进Redis。审计时被一票否决。正确姿势：在MemoryService.write()入口，用正则(\d{4})\d{10}(\d{4})匹配身份证号，替换为$1****$2，再存入。所有敏感字段（手机号、银行卡号）都走同一套脱敏管道。

5.3 性能调优实战：从42ms到8ms的向量检索优化

某客户抱怨“查政策文件太慢”，我们用Arthas追踪发现，VectorStoreIndex.query()耗时42ms，其中38ms花在MilvusClient.search()。优化步骤：

1. 确认Milvus配置：grep "cache.cache_size" /etc/milvus/config.yaml，发现cache.cache_size: 2GB，而服务器内存32GB，调至16GB；
2. 优化索引参数：原用IVF_FLAT，改为IVF_SQ8（量化压缩），建索引时nlist=1000（原为100），召回率从92%升至95%，搜索耗时降至15ms；
3. 预热缓存：服务启动时，用milvus_client.load_collection("policy_docs")主动加载索引到内存；
4. 批处理：将单次查询query_vector改为批量（10个向量一次发），Milvus的batch search性能提升3倍。

最终，VectorStoreIndex.query()P95延迟从42ms降至8ms，用户感知从“稍等一下”变为“秒出结果”。

6. 范式迁移的组织挑战：当工程师开始质疑“为什么Plan必须是LLM生成的”

“物理外化”不仅是技术方案，更是思维范式的切换。最大的阻力往往来自团队内部。我们经历过三次典型的认知冲突：

冲突1：LLM purist vs. Rule engine pragmatist
新人工程师坚持“所有Plan必须由LLM生成，否则不叫AI Agent”。而资深工程师指出：“LLM生成的Plan在促销季会把‘满300减50’错写成‘满300减500’，而规则引擎的Drools规则when $o: Order(total >= 300) then $o.setDiscount(50)，经过QA测试，100%准确。” 最终妥协方案：LLM只生成“创意型Plan”（如营销文案生成），规则引擎处理“确定型Plan”（如订单查询、物流跟踪），两者通过PlanType字段路由。

冲突2：框架信仰者 vs. 运维现实主义者
有工程师想用Spring AI统一抽象LLM调用，但SRE反对：“Spring AI的ChatClient不支持OpenAI的response_format={type: 'json_object'}参数，而我们的审计要求必须JSON输出。” 我们选择放弃Spring AI，直接用OpenAI官方Java SDK，虽然代码多写20行，但保证了参数100%可控。

冲突3：敏捷迭代派 vs. 合规保守派
产品经理要求“下周上线新Tool”，但法务要求“所有Tool调用必须有用户二次确认弹窗”。技术方案是：在ToolDispatcher中拦截tool_name='transfer_money'，返回{"need_confirmation": true, "message": "确认向张三转账1000元？"}，前端渲染弹窗，用户点击“确认”后，再发第二条Kafka消息触发真实调用。这增加了1次RTT，但满足了合规底线。

我个人在实际操作中的体会是：Agent工程化的终点，不是做出最炫酷的AI效果，而是让AI行为像水电煤一样，成为基础设施的一部分——稳定、可计量、可审计、可替换。当你的CTO能指着Grafana看板说“今天LLM Token成本超预算了，把get_stock_price的max_tokens从2000调到1000”，而不是问“那个AI为啥又胡说了”，你就真正完成了范式迁移。