构建可靠系统：从可观测性到AI应用，应对分布式与AI幻觉挑战

最近在技术社区里，一个名为“三花聚顶本是幻，脚下腾云亦非真”的项目标题引起了我的注意。初看之下，这更像一句充满禅意的诗句，而非一个技术项目。这恰恰是它最有趣的地方：一个技术项目，为何要借用如此抽象、甚至带有哲学思辨色彩的标题？它想表达什么？是故弄玄虚，还是背后真有一套独特的技术理念？

经过一番探究，我发现这个标题并非空穴来风。它指向的是一种在当下分布式系统、云原生和AI Agent开发中日益凸显的深层矛盾：我们构建的系统越来越复杂、越来越“智能”，仿佛拥有了“三花聚顶”般的强大能力，但其底层依赖的基础设施（“脚下腾云”）却可能脆弱、不稳定，甚至充满幻觉。这个项目，本质上是在探讨如何在这种矛盾中，构建真正可靠、可观测、可理解的系统。

简单来说，它关注的是“系统的真实性与可靠性”问题。在微服务架构中，一个API调用失败，原因可能藏在链路追踪的某个角落；在AI应用中，一个看似合理的回答，其推理过程可能基于错误的数据或逻辑（即“幻觉”）；在云原生环境下，容器说崩就崩，网络说断就断。我们引以为傲的“腾云驾雾”般的技术栈，其根基并非总是坚实可靠。

因此，这篇文章将围绕这个核心议题展开。我不会去复述一句诗的文学含义，而是会深入技术层面，拆解“三花聚顶”（系统上层复杂能力）与“脚下腾云”（底层基础设施可靠性）之间的张力。我们将探讨：

1. 如何通过系统设计、监控、可观测性等手段，让“腾云”变得更“真”。
2. 如何识别和抵御AI系统中的“幻觉”，确保输出可靠。
3. 分享一套可落地的实践框架，包括工具链、设计模式和代码示例，帮助你在项目中构建更具韧性的系统。

如果你正在为微服务的调试、AI应用的不可预测性、或分布式系统的稳定性而头疼，那么这篇文章正是为你准备的。我们将从理念到实践，一步步揭开“幻”与“真”背后的工程技术。

1. 从一句诗到一类工程问题：我们到底在解决什么？

“三花聚顶本是幻，脚下腾云亦非真。” 在技术语境下，我们可以做一次直接的映射：

• “三花聚顶”：代表我们为系统赋予的复杂、高阶的能力。例如：
  • 一个能进行多轮对话、理解上下文、完成复杂任务的AI Agent。
  • 一个由数十个微服务协同工作，实现秒级响应的电商下单链路。
  • 一个能自动扩缩容、自愈、进行金丝雀发布的智能运维平台。 这些能力光彩夺目，是系统的“顶”，是业务价值的直接体现。
• “脚下腾云”：代表支撑这些能力的基础设施和底层依赖。例如：
  • 云服务器、容器、网络、存储。
  • 数据库、消息队列、缓存。
  • 第三方API、模型服务、数据管道。 这些是系统的“脚”，是默默无闻的基石，但往往也是故障的来源。
• “幻”与“非真”：揭示了理想与现实的差距。上层能力构建在脆弱的、不可控的、甚至会产生错误信息（幻觉）的底层之上。这种差距就是工程师日常需要面对的“坑”：
  • AI幻觉：模型自信地给出一个完全错误的答案，且逻辑自洽。
  • 分布式谬误：网络是可靠的、延迟为零、带宽无限、拓扑不变、只有一个管理员、传输成本为零、网络是同构的——这些假设在现实中都不成立。
  • 观测黑盒：系统出问题了，但日志、指标、链路追踪无法告诉你根本原因在哪里，你像是在迷雾中调试。
  • 依赖爆炸：一个核心下游服务挂掉，导致整个调用链雪崩。

所以，这个项目标题所引发的思考，其核心是“如何在我们无法完全控制的基础设施上，构建出可靠、可信的系统”。这不是一个具体的工具或框架，而是一套工程哲学和最佳实践的集合。接下来的内容，我们将把它拆解为可执行的技术方案。

2. 核心概念拆解：可靠性、可观测性与韧性

在深入实践之前，我们需要统一几个关键概念的理解。这些概念是构建“真实”系统的基石。

2.1 可靠性 vs. 可用性

很多人会混淆这两个词，但它们侧重点不同。

• 可用性：系统能够提供服务的时间比例。通常用“几个9”来衡量（如99.9%）。它关注的是“是否在线”。
• 可靠性：系统在规定条件下和规定时间内，无故障地执行所需功能的能力。它更关注“功能是否正确”。一个系统可能可用（能访问），但不可靠（返回错误结果）。我们追求的是在可用的基础上，实现可靠。

2.2 可观测性

这是近年来超越“监控”的更高阶概念。

• 监控：你预先定义好一组指标（如CPU使用率、错误率），然后观察它们是否超过阈值。它是“已知的未知”。
• 可观测性：当系统出现未知的未知故障时，你能否通过系统外部输出的信息（日志、指标、链路），快速定位和理解内部状态？可观测性基于三大支柱：
  1. 日志：离散的、带时间戳的事件记录。用于记录“发生了什么”。
  2. 指标：随时间聚合的数值数据。用于回答“系统整体表现如何”。
  3. 链路追踪：记录单个请求在分布式系统中流经的所有服务。用于回答“为什么这个请求这么慢/失败了”。

2.3 系统韧性

韧性是指系统在遭受冲击（如流量激增、依赖故障、网络分区）后，能够维持核心功能，并快速恢复的能力。它包含的模式有：

• 熔断：当下游服务失败率达到阈值时，快速失败，避免资源耗尽。
• 降级：当系统压力过大时，暂时关闭非核心功能，保障核心流程。
• 重试：对暂时性故障进行有限次数的重试。
• 限流：控制请求速率，保护系统不被冲垮。
• 超时：为所有外部调用设置合理的超时时间，避免无限等待。

理解了这些概念，我们就有了共同的语言。接下来，我们将从“脚下腾云”（基础设施与依赖）和“三花聚顶”（上层应用与AI）两个层面，分别探讨如何让它们变得更“真”。

3. 环境与工具链准备

工欲善其事，必先利其器。构建可靠、可观测的系统，需要一套现代化的工具链。以下是一个推荐的技术栈，你可以根据实际项目情况选用。

核心工具栈：

前置条件：

1. 操作系统：Linux (Ubuntu 20.04+/CentOS 7+) 或 macOS。本文示例以Linux为主。
2. 基础环境：安装Docker和Docker Compose。这将帮助我们快速搭建演示环境。
3. 代码编辑器：VS Code、IntelliJ IDEA等。

我们首先使用Docker Compose搭建一个最小化的可观测性技术栈，用于后续的演示。

# docker-compose-observability.yml version: '3.8' services: # 指标收集与告警 prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--web.console.libraries=/etc/prometheus/console_libraries' - '--web.console.templates=/etc/prometheus/consoles' - '--storage.tsdb.retention.time=200h' - '--web.enable-lifecycle' ports: - "9090:9090" networks: - observability-net # 指标可视化 grafana: image: grafana/grafana:latest container_name: grafana ports: - "3000:3000" volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORD=admin networks: - observability-net # 链路追踪 jaeger: image: jaegertracing/all-in-one:latest container_name: jaeger ports: - "16686:16686" # UI - "14268:14268" # 接收客户端数据 - "6831:6831/udp" # 接收Jaeger原生协议 networks: - observability-net volumes: prometheus_data: grafana_data: networks: observability-net: driver: bridge

对应的Prometheus基础配置：

# prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] # 后续我们会在这里添加我们应用的监控目标

启动这个环境：

docker-compose -f docker-compose-observability.yml up -d

启动后，你可以访问：

• Prometheus:http://localhost:9090
• Grafana:http://localhost:3000(用户名admin, 密码admin)
• Jaeger UI:http://localhost:16686

这个环境将作为我们后续验证系统“真实性”的观察窗口。

4. 实践一：让“脚下腾云”变真——构建可观测的微服务

我们构建一个简单的模拟微服务应用，它包含两个服务：order-service（订单服务）和inventory-service（库存服务）。订单服务会调用库存服务。我们将为它们注入完整的可观测性。

4.1 项目结构与依赖

使用Spring Boot (Java) 作为示例，但理念通用。

1. 订单服务 (order-service)pom.xml关键依赖：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- OpenTelemetry 自动注入 --> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-spring-boot-starter</artifactId> <version>2.5.0-alpha</version> <!-- 请使用最新稳定版 --> </dependency> <!-- Micrometer 对接 Prometheus --> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- Resilience4j 实现韧性 --> <dependency> <groupId>io.github.resilience4j</groupId> <artifactId>resilience4j-spring-boot2</artifactId> <version>2.2.0</version> </dependency> </dependencies>

2. 应用配置 (application.yml):

# order-service/src/main/resources/application.yml server: port: 8081 management: endpoints: web: exposure: include: health, info, prometheus, metrics metrics: export: prometheus: enabled: true tracing: sampling: probability: 1.0 # 全量采样，生产环境可调低 spring: application: name: order-service # OpenTelemetry 配置，将数据导出到Jaeger opentelemetry: exporter: jaeger: endpoint: http://localhost:14250 # Jaeger的gRPC端点 service-name: ${spring.application.name} # Resilience4j 熔断器配置 resilience4j: circuitbreaker: instances: inventoryService: failure-rate-threshold: 50 sliding-window-size: 10 minimum-number-of-calls: 5 wait-duration-in-open-state: 10s

4.2 核心代码实现

订单服务控制器：

// OrderServiceApplication.java package com.example.orderservice; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }

// OrderController.java package com.example.orderservice.controller; import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker; import io.micrometer.core.annotation.Timed; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; import org.springframework.web.client.RestTemplate; @RestController @RequestMapping("/orders") public class OrderController { @Autowired private RestTemplate restTemplate; private static final String INVENTORY_SERVICE_URL = "http://localhost:8082/inventory"; @PostMapping @Timed(value = "order.create", description = "创建订单耗时") // 自定义指标 @CircuitBreaker(name = "inventoryService", fallbackMethod = "createOrderFallback") public ResponseEntity<String> createOrder(@RequestBody OrderRequest request) { // 1. 调用库存服务，检查库存 ResponseEntity<String> inventoryResponse = restTemplate.postForEntity( INVENTORY_SERVICE_URL + "/check-and-deduct", request, String.class ); if (!inventoryResponse.getStatusCode().is2xxSuccessful()) { return ResponseEntity.status(503).body("库存服务异常，订单创建失败"); } // 2. 模拟创建订单逻辑 // ... 数据库操作等 return ResponseEntity.ok("订单创建成功，商品: " + request.getProductId() + ", 数量: " + request.getQuantity()); } // 熔断降级方法 public ResponseEntity<String> createOrderFallback(OrderRequest request, Throwable t) { // 记录降级日志，这里可以接入更复杂的降级逻辑，如返回缓存数据、排队等 // 使用Slf4j的MDC或OpenTelemetry API可以在此处添加上下文信息 return ResponseEntity.status(503).body("服务暂时不可用，请稍后重试（降级处理）"); } }

库存服务 (inventory-service) 类似配置，运行在8082端口。为了演示故障，我们可以在库存服务中随机模拟失败：

// InventoryController.java (inventory-service) @RestController @RequestMapping("/inventory") public class InventoryController { private Random random = new Random(); @PostMapping("/check-and-deduct") public ResponseEntity<String> checkAndDeduct(@RequestBody OrderRequest request) { // 模拟30%的失败率 if (random.nextInt(10) < 3) { // 模拟服务内部错误或超时 try { Thread.sleep(5000); // 模拟长时间阻塞 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return ResponseEntity.status(500).body("库存服务内部错误"); } // 正常处理逻辑 return ResponseEntity.ok("库存检查与扣减成功"); } }

4.3 集成与运行验证

1. 启动服务：分别启动order-service和inventory-service。
2. 配置Prometheus抓取：修改之前的prometheus.yml，添加两个服务的监控端点。

   scrape_configs: - job_name: 'spring-boot-apps' metrics_path: '/actuator/prometheus' static_configs: - targets: ['host.docker.internal:8081', 'host.docker.internal:8082'] # macOS/Windows Docker Desktop # 如果是Linux原生环境，使用 'localhost:8081' # 或者使用Docker服务名，如果服务都在同一个docker-compose网络中 # - targets: ['order-service:8081', 'inventory-service:8082']

   重启Prometheus容器使其生效。
3. 生成流量与观察：使用curl或Postman频繁调用POST http://localhost:8081/orders。

   # 模拟并发请求 for i in {1..50}; do curl -X POST http://localhost:8081/orders \ -H "Content-Type: application/json" \ -d '{"productId":"item_$i", "quantity":1}' & done wait

观察结果：

1. Prometheus：查询resilience4j_circuitbreaker_state指标，可以看到inventoryService熔断器的状态变化（CLOSED -> OPEN -> HALF_OPEN -> CLOSED）。查询order_create_seconds_count可以看到接口调用次数和耗时分布。
2. Grafana：配置Dashboard，可视化上述指标，直观看到错误率上升、熔断器打开、请求被降级的过程。
3. Jaeger：搜索order-service的链路，可以看到一次订单创建请求的完整生命周期，包括对inventory-service的调用。当调用失败或超时时，链路中会清晰显示错误和耗时。

通过这个实践，我们为系统装上了“眼睛”和“免疫系统”。当“脚下腾云”（库存服务）出现不稳定时，“三花聚顶”（订单服务）通过熔断和降级机制保持了核心可用性，并通过可观测性工具让我们能迅速定位问题根源。这就是让“非真”的基础设施，支撑起“相对可靠”的上层业务的方法。

5. 实践二：抵御“三花聚顶”之幻——构建可靠的AI应用

AI应用，尤其是大语言模型应用，其“幻觉”问题尤为突出。模型可能生成看似合理但完全错误或有害的内容。如何让AI应用变得更“真”？我们需要从流程和架构上加以约束。

5.1 问题场景：一个基于LLM的客服问答系统

假设我们有一个客服问答Agent，用户问：“我昨天买的订单12345，现在到哪了？” 一个不可靠的AI系统可能：

1. 幻觉：编造一个不存在的物流信息。
2. 越权：在未验证用户身份的情况下，就查询了订单信息。
3. 错误理解：把“订单12345”理解成一个产品型号。

5.2 解决方案：工具调用与流程编排

核心思想是：不让LLM直接生成最终答案，而是让它学会调用可靠的工具（函数），并将工具执行的结果整合进回答。这就是所谓的“Function Calling”或“Tool Calling”。

我们使用Python和LangChain框架来演示一个更可靠的流程。

1. 环境准备：

pip install langchain langchain-openai tavily-python

假设我们使用OpenAI的GPT模型和Tavily搜索API。

2. 定义可靠的工具（函数）：

# tools.py import json from typing import Type, Any from pydantic import BaseModel, Field from langchain.tools import BaseTool, StructuredTool # 模拟一个可靠的订单查询数据库函数 def query_order_from_db(order_id: str, user_id: str) -> str: """ 根据订单ID和用户ID查询订单状态。 这是一个可靠的内部函数，连接真实数据库。 """ # 这里应该是真实的数据库查询逻辑，并做权限校验（user_id是否匹配该订单） # 为演示，我们返回模拟数据 if order_id == "12345" and user_id == "user_001": return json.dumps({ "status": "shipped", "tracking_number": "SF123456789", "estimated_delivery": "2023-10-27" }) else: return json.dumps({"error": "订单不存在或无权访问"}) # 将函数封装为LangChain Tool class OrderQueryInput(BaseModel): order_id: str = Field(description="订单编号") user_id: str = Field(description="用户ID，用于权限验证") order_query_tool = StructuredTool.from_function( func=query_order_from_db, name="query_order_status", description="根据订单ID和用户ID查询物流状态。必须提供用户ID进行验证。", args_schema=OrderQueryInput, return_direct=True, # 工具返回的结果直接作为最终输出的一部分 ) # 再定义一个网络搜索工具，用于回答通用知识问题 from langchain_community.tools.tavily_search import TavilySearchResults search_tool = TavilySearchResults()

3. 构建具有约束的Agent流程：

# reliable_agent.py import os from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_structured_chat_agent from langchain.memory import ConversationBufferMemory from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools.render import format_tool_to_openai_function from langchain_core.messages import SystemMessage # 1. 定义系统提示词，约束AI行为 system_prompt = SystemMessage(content="""你是一个可靠的客服助手。请严格遵守以下规则： 1. 当用户询问订单状态时，你必须要求用户提供身份信息（如用户ID），并使用`query_order_status`工具进行查询。严禁编造物流信息。 2. 对于其他通用问题，你可以使用网络搜索工具。 3. 如果你不知道或不确定，请明确告知用户，不要猜测。 4. 所有关于订单、账户等敏感操作，必须通过工具完成，不得自行生成信息。""") prompt = ChatPromptTemplate.from_messages([ system_prompt, MessagesPlaceholder(variable_name="chat_history"), ("human", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), ]) # 2. 初始化LLM和工具 llm = ChatOpenAI(model="gpt-4", temperature=0) # 低temperature减少随机性 tools = [order_query_tool, search_tool] llm_with_tools = llm.bind(functions=[format_tool_to_openai_function(t) for t in tools]) # 3. 创建Agent agent = create_structured_chat_agent( llm=llm_with_tools, tools=tools, prompt=prompt ) memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) agent_executor = AgentExecutor.from_agent_and_tools( agent=agent, tools=tools, memory=memory, verbose=True, # 打印详细执行过程，便于调试 handle_parsing_errors=True, # 处理解析错误 max_iterations=3 # 限制最大循环次数，防止死循环 ) # 4. 运行测试 if __name__ == "__main__": # 测试1：用户未提供ID，Agent应要求提供 print("=== 测试1：用户询问订单但未提供ID ===") result1 = agent_executor.invoke({"input": "我的订单12345到哪了？"}) print(result1["output"]) print("\n") # 测试2：用户提供ID，Agent调用工具查询 print("=== 测试2：用户提供ID后查询 ===") result2 = agent_executor.invoke({"input": "我的用户ID是user_001，请查一下订单12345的状态。"}) print(result2["output"]) print("\n") # 测试3：通用知识问题，使用搜索 print("=== 测试3：通用知识问题 ===") result3 = agent_executor.invoke({"input": "LangChain是什么？"}) print(result3["output"])

5.3 运行结果与效果验证

运行上述脚本，你将看到类似以下输出：

=== 测试1：用户询问订单但未提供ID === > Entering new AgentExecutor chain... 我需要查询您的订单状态，但为了安全起见，请提供您的用户ID以便验证身份。 > Finished chain. 我需要查询您的订单状态，但为了安全起见，请提供您的用户ID以便验证身份。 === 测试2：用户提供ID后查询 === > Entering new AgentExecutor chain... Action: query_order_status Action Input: {"order_id": "12345", "user_id": "user_001"} Observation: {"status": "shipped", "tracking_number": "SF123456789", "estimated_delivery": "2023-10-27"} Thought:我已经通过工具查询到订单状态。 Final Answer: 您的订单12345已发货，运单号是SF123456789，预计送达时间为2023年10月27日。 > Finished chain. 您的订单12345已发货，运单号是SF123456789，预计送达时间为2023年10月27日。

关键验证点：

1. 约束生效：当用户未提供ID时，Agent没有尝试编造答案，而是要求提供信息。
2. 工具调用：当信息齐全时，Agent正确调用了query_order_status工具，并将工具返回的结构化数据转换成了自然语言回答。
3. 来源可靠：答案基于我们定义的、可靠的query_order_from_db函数，而不是LLM的“记忆”或“想象”。
4. 流程透明：设置verbose=True后，我们可以清晰看到Agent的思考过程（Chain of Thought）和工具调用记录，这对于调试和审计至关重要。

通过这种方式，我们将AI的“创造性”限制在流程编排和语言组织上，而将事实核查、数据获取、权限验证等关键任务交给可靠的程序（工具）。这极大地减少了“幻觉”的发生，让AI应用的输出建立在“真实”的数据基础之上。

6. 常见问题与排查思路

在实践上述模式时，你可能会遇到一些典型问题。以下是一个快速排查指南。

7. 最佳实践与工程建议

将“幻”变为“真”是一个系统工程，以下是一些贯穿设计、开发、运维全流程的最佳实践。

7.1 设计阶段：拥抱“混沌工程”思想

• 假设故障一定会发生：在设计之初，就考虑每个依赖（数据库、API、网络）都可能失败。问自己：“如果这个服务挂了，我的系统会怎样？”
• 定义SLO/SLI：为服务制定明确的可服务等级目标（SLO）和指标（SLI），例如“订单创建API的99%请求延迟低于200ms”。这为可靠性提供了可衡量的目标。
• 设计降级方案：明确系统的核心功能和非核心功能。当系统过载或部分故障时，如何优雅地降级（例如，关闭商品推荐，保障下单流程）？

7.2 开发阶段：代码即防御

• 为所有外部调用设置超时和重试：这是防止级联失败的第一道防线。重试策略需谨慎（如指数退避），避免加重下游负担。

  // 使用Resilience4j的@Retry注解 @Retry(name = "inventoryService", fallbackMethod = "fallback") public String callExternalService() { ... }

• 实施全面的日志记录：日志不仅要记录“发生了什么”，还要记录“为什么发生”。使用结构化日志（JSON格式），并注入请求ID、用户ID等上下文，方便链路追踪。
• 在AI应用中，严格校验工具输入输出：对Tool Calling的输入参数进行合法性校验（如用户ID格式），对工具返回的结果进行解析和有效性判断，防止脏数据导致后续流程错误。

7.3 部署与运维阶段：可观测性驱动

• 建立统一的可观测性平台：将日志、指标、链路数据集中收集和关联。在Grafana中制作面向不同角色（开发、运维、产品）的Dashboard。
• 设置有意义的告警：避免“告警疲劳”。告警应基于SLO，而不是简单的阈值。例如，“错误率在5分钟内持续高于1%”比“有一个错误”更有意义。
• 进行定期的故障演练（混沌实验）：在可控的测试或预发环境中，主动注入故障（如杀死容器、模拟网络延迟、让某个API返回错误），验证系统的韧性预案是否真正有效。

7.4 针对AI应用的特别建议

• 将LLM视为一个有才华但不可靠的实习生：你可以让它写草稿、提建议、整理信息，但所有关键决策、数据获取和最终输出，都必须经过可靠的工具或人工校验流程。
• 实现“人机回环”：对于高风险或高不确定性的AI输出，设计流程将其路由给人工审核。例如，客服系统中涉及退款、投诉的复杂问题，先由AI生成建议回复，再由人工确认发出。
• 持续评估与迭代：建立AI输出的评估体系，包括准确性、安全性、有用性等维度。利用这些反馈持续优化提示词、工具设计和流程。

“三花聚顶本是幻，脚下腾云亦非真。” 这句充满禅意的话，为我们揭示了一个深刻的技术现实：在复杂系统与AI时代，表面的强大功能之下，是无数脆弱且不确定的依赖。追求技术的“真”，并非追求绝对的完美与稳定，而是通过系统的设计，在“幻”与“非真”中，建立起足够的韧性、可观测性与控制力。

本文从两个核心维度提供了实践路径：在微服务架构中，我们通过可观测性三大支柱和韧性模式，让不稳定的基础设施变得透明、可控；在AI应用中，我们通过工具调用和流程编排，将LLM的创造力约束在可靠的业务逻辑和数据源之上。这两条路径的共同点，都是用确定性的程序逻辑，去管理和约束不确定性的部分。

技术之路，就是一场不断识别幻觉、夯实基础的修行。希望这篇文章提供的工具、代码和思路，能帮助你构建出更可靠、更真实、更值得信赖的系统。建议收藏本文，在下次遇到“幻”与“非真”的挑战时，不妨回来看看这些实践，或许能找到新的灵感。