在效率优先的软件开发语境中AI 正在变成一种新的效率图腾甚至一种库哈斯式隐喻大模型平台像巨型机场一样矗立在算力荒原上AI Agent 则像自动扶梯一样把人类输送给效率本身。库哈斯Rem Koolhaas在《疯狂的纽约》和《S,M,L,XL》里反复讨论过一种现象现代建筑不再是为了居住而是为了“吞吐量”而存在。机场、购物中心、数据机房这些建筑的本质是流程机器。今天的 AI 系统也呈现出同样的特征它不再只是工具而是一套关于效率的信仰体系。开发者调用大模型 API产品经理设计 Agent 工作流运营者搭建 RAG 知识库所有人都像朝圣者一样围绕“更快、更省、更智能”构建系统。这篇文章试图把库哈斯的建筑隐喻映射到 AI 工程实践上模型是祭坛API 是祭品通道Agent 是祭司而提示词则是祈祷词。但这篇文章不会停留在比喻层面。我会把它落成一条可操作的技术主线先理解 AI 工程中的效率崇拜逻辑再搭建一个最小可运行的 Agent 项目然后用日志、参数和错误现象验证系统是否真的“高效”最后讨论生产环境下需要什么样的工程纪律来对抗过度效率化带来的脆弱性。读完这篇内容你能得到三样东西。第一一套理解 AI 工程结构的隐喻模型帮助你向非技术人员解释为什么 Agent 系统容易失控。第二一个基于 Python 和大模型 API 的最小 Agent 示例包含提示词、工具调用、JSON 输出和错误处理。第三一份可以在真实项目中使用的排查清单和避坑指南覆盖超时、幻觉、上下文截断、成本失控等常见问题。1. 库哈斯式隐喻从建筑“吞吐量”到 AI 效率崇拜1.1 为什么 AI 系统越来越像一座“机场”库哈斯在分析纽约曼哈顿时提出过一个观点摩天楼不是立面艺术而是一种“密度机器”。每一层都在吞吐人流、电力、信息和资本。建筑的功能不再由外观决定而是由内部流程的效率决定。这个判断放在今天的 AI 系统上几乎完全成立。一个典型的深度学习训练集群物理上是一排机柜逻辑上是一套吞吐流数据进、梯度出、参数更新。一个生产环境的 RAG 应用逻辑上是一套检索管道文档切片、向量化、召回、重排、生成。没有人关心页面长什么样所有人只关心延迟、吞吐量、Token 消耗、召回率。这已经不是为了“解决某个问题”而存在的工具而是为了“更快地处理信息”而存在的基础设施。库哈斯式的隐喻在这里的价值是它提醒我们效率系统的设计者容易陷入“流程本身”的狂热而忘记流程的终点是什么。就像机场为了吞吐效率可以牺牲人的空间体验AI 系统为了 Token 效率可以牺牲答案质量、提示词可读性和维护性。开发者不应该只看到“能跑”还要看到“它正在吞掉什么”。1.2 从“大教堂”到“数据教堂”再到“模型祭坛”库哈斯在讨论欧洲大教堂时注意到哥特式教堂的剖面本质上是一条人流通道入口、中殿、祭坛、侧廊每一个空间都服务于宗教仪式的流程。中世纪的建造者用石头和光线控制朝圣者的情绪。今天的 AI 系统用提示词、模型温度和上下文窗口控制使用者的预期。把这个隐喻展开模型是祭坛它是系统中最“神圣”的部分不透明、不可解释但大家都相信它有超自然能力。API 是祭品通道每一次调用都意味着消耗 Token就像祭品被投入火焰。Agent 是祭司它负责解释模型输出、管理对话流程、决定何时调用工具。提示词是祈祷词同样的信念不同的人念出来效果不同但只要结果不够好人们总是先怀疑“祷词写得不对”。这个隐喻不是玩笑而是工程上的真实映射。AI 系统的开发难点往往不在模型本身而在围绕模型建立的流程。谁会调用模型、调用前要拼装什么上下文、调用后如何校验输出、失败时如何降级这些才是 Agent 工程的核心。而“效率”就是这个系统的教义谁能在最少的 Token 内完成任务谁就是更好的实现。1.3 隐喻给工程实践带来的三个判断把库哈斯的视角引入 AI 工程可以形成三条可执行的判断。第一流程效率不等于系统质量。一个 Token 消耗极少的 Agent 可能在语义理解上非常脆弱。就像库哈斯批评过的“过度服务化的建筑”一样流程越合理空间可能越空洞。第二系统的可见性比美观更重要。库哈斯的设计图纸非常重视流线分析和功能分区而不是立面效果。AI 工程也应该如此日志、追踪、输入输出留痕比模型选型更值得投入资源。第三效率是一种选择不是默认值。设计 Agent 时要明确回答一个问题我们优化的是速度、成本、质量还是三者平衡。不同目标会导向完全不同的架构。比如一个面向客服的 Agent必须牺牲一些 Token 效率换取意图理解的鲁棒性。注意库哈斯式隐喻在这里是分析工具不是装饰。工程中真正有用的不是“AI 像宗教”这句话而是它带来的检查视角系统为谁服务流程是否吞掉了目的效率是否取代了判断。2. AI 工程的最小骨架模型、API、上下文与 Agent2.1 先拆术语模型、端侧推理、云端 API 与本地部署在进入代码之前需要先把术语对齐。AI 工程里的“模型”不是指 ChatGPT 或某个具体产品而是指权重文件本身例如Qwen2.5-7B-Instruct、Llama-3.1-8B-Instruct、GPT-4o等。模型需要被“部署”成可调用的服务这个服务可以是云端 API也可以是本地进程。工程实践中常见的三种使用方式使用方式典型场景优势需要注意的问题云端托管 API快速原型、生产级应用无需准备 GPU开箱即用数据出网、按 Token 计费、限流本地部署推理服务私有化项目、离线环境数据不出内网可控性强需要 GPU 或高性能 CPU环境配置复杂嵌入式推理边缘端端侧智能、小模型延迟低、可离线模型参数量小能力受限文章后面的示例会使用“OpenAI 兼容协议”的 API 方式来连接模型服务这样既可以接云端服务也可以接本地推理框架。实际项目使用什么模型要根据自己可用的资源、数据隐私要求和成本预算决定。2.2 理解 Token、上下文窗口和温度参数Token 是模型处理文本的最小单位可以理解成一个词的一部分或一个常见符号的组合。英文单词大约 1 个 Token 对应 0.75 个词中文一个汉字大约需要 1 到 2 个 Token。模型能处理的输入和输出总长度受上下文窗口限制典型的窗口大小有 4K、8K、32K、128K 等。温度参数控制输出的随机性。温度越低输出越稳定、越接近概率最高的文本温度越高输出越发散、越有“创造性”。工程场景下结构化输出、数据抽取和代码生成通常使用 0 到 0.3 之间的温度创意写作和头脑风暴可以使用 0.7 到 1.0。参数对系统行为的影响可以用一句话概括上下文窗口决定“它能看到多少”温度决定“它有多敢编”。在实际项目中这两个参数必须显式配置而不是放任默认值。很多线上问题的根源就是这两个参数没有根据场景调整例如用 1.0 的温度做关键信息抽取导致同样的输入每次输出都不一样。2.3 从裸调用到 Agent为什么要有一层“胶水代码”只调用大模型 API 并不足以支撑实际业务。原因有三个。第一模型没有记忆。它只处理你本次请求传入的对话消息不会记得上一次调用。所谓“多轮对话”其实是开发者自己维护历史记录并把它们重新发给模型。第二模型不知道外部世界。它无法查询数据库、调用订单接口、读取文件系统和访问网页除非你通过工具调用机制把这些能力接进去。第三模型输出不稳定。你让它返回 JSON它可能返回带说明文字的 JSON、被 Markdown 代码块包裹的 JSON甚至不是合法 JSON。这层胶水代码负责修正和兜底。所以实际工程中必须在模型前面加一层封装这套封装今天流行叫 Agent。Agent 的核心工作是维护状态、拼装消息、选择工具、解析模型输出、处理错误、记住临时结果。3. 亲手搭建一个最小 AI 效率系统本地大模型加 Python Agent3.1 环境准备Python 虚拟环境与模型服务为了演示 Agent 的完整链路我推荐先使用本地推理服务。这样不依赖外部网络、成本可控也方便抓日志。准备条件Python 3.10 或更高版本一个本地推理框架例如 Ollama 或其他能提供 OpenAI 兼容 API 的推理服务一台至少有 16GB 内存的电脑用于运行 7B 量级的量化模型创建虚拟环境并安装依赖mkdir ai-agent-demo cd ai-agent-demo python3 -m venv venv source venv/bin/activate pip install openai python-dotenv这里使用openai这个 Python 包并不代表必须连接 OpenAI 官方服务。它可以配置成任何 OpenAI 兼容的接口地址。这样写的好处是本地开发和云端迁移共用同一套代码。启动本地推理服务ollama pull qwen2.5:7b ollama serve验证服务是否可用curl http://localhost:11434/v1/models正常情况会返回一个包含模型列表的 JSON。这一步是后面的所有调用的基础。注意如果你在生产环境使用云端模型服务不需要启动本地推理服务只需要配置OPENAI_API_KEY和OPENAI_BASE_URL两个环境变量。下面的代码会兼容这两种方式。3.2 项目结构设计把“提示词”和“流程”分开项目结构决定代码的可维护性。一个最小 Agent 项目可以分成四个文件ai-agent-demo/ ├── .env ├── config.py ├── llm.py ├── agent.py └── main.pyconfig.py统一读取环境变量和模型参数。llm.py封装大模型 API负责连接、超时和重试。agent.py实现 Agent 的核心流程拼装消息、解析输出、调用工具。main.py入口脚本模拟用户输入输出 Agent 的决策过程。把提示词和流程分开的好处是提示词经常要调整但流程代码不应该每次跟着改。工程上的习惯是提示词可以放在独立文件夹甚至配置中心后续做 A/B 测试也会更方便。3.3 核心代码一个能查天气和算加法的最小 Agent下面的代码演示一个最小但完整的 Agent。它只能做两件事计算加法、查询指定城市的天气用模拟数据代替真实 API但已经包含了 Agent 工程的基本要素。config.pyimport os from dotenv import load_dotenv load_dotenv() MODEL_NAME os.getenv(MODEL_NAME, qwen2.5:7b) BASE_URL os.getenv(OPENAI_BASE_URL, http://localhost:11434/v1) API_KEY os.getenv(OPENAI_API_KEY, ollama) TEMPERATURE float(os.getenv(TEMPERATURE, 0.2)) MAX_TOKENS int(os.getenv(MAX_TOKENS, 1024)) TIMEOUT int(os.getenv(TIMEOUT, 60))llm.pyfrom openai import OpenAI from config import MODEL_NAME, BASE_URL, API_KEY, TEMPERATURE, MAX_TOKENS, TIMEOUT class LLMClient: def __init__(self): self.client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) def chat(self, messages, response_formatNone): params { model: MODEL_NAME, messages: messages, temperature: TEMPERATURE, max_tokens: MAX_TOKENS, timeout: TIMEOUT, } if response_format is not None: params[response_format] response_format resp self.client.chat.completions.create(**params) return resp.choices[0].message.contentagent.pyimport json from llm import LLMClient TOOLS [ { type: function, function: { name: add, description: 计算两个整数的和, parameters: { type: object, properties: { a: {type: integer, description: 第一个加数}, b: {type: integer, description: 第二个加数}, }, required: [a, b], }, }, }, { type: function, function: { name: get_weather, description: 获取指定城市的天气信息, parameters: { type: object, properties: { city: {type: string, description: 城市名}, }, required: [city], }, }, }, ] SYSTEM_PROMPT ( 你是一个只负责处理结构化任务的助手。 当用户请求涉及计算或天气时你必须调用对应工具。 不要编造工具结果等待工具返回值后再回答。 最终回答必须简洁直接给出结果。 ) class Agent: def __init__(self): self.llm LLMClient() self.messages [ {role: system, content: SYSTEM_PROMPT}, ] def run(self, user_input: str) - str: self.messages.append({role: user, content: user_input}) for step in range(3): resp self.llm.chat(self.messages) parsed self._parse_response(resp) if parsed[type] text: self.messages.append({role: assistant, content: parsed[content]}) return parsed[content] if parsed[type] tool_call: tool_result self._execute_tool(parsed[name], parsed[arguments]) self.messages.append({role: assistant, content: resp}) self.messages.append({ role: tool, tool_call_id: parsed[id], content: json.dumps(tool_result, ensure_asciiFalse), }) return Agent 执行超过最大步骤请检查提示词或工具定义。 def _parse_response(self, resp: str): try: data json.loads(resp) if tool_call in data and data[tool_call]: return { type: tool_call, id: data.get(id, call_001), name: data[tool_call][name], arguments: data[tool_call][arguments], } return {type: text, content: data.get(answer, resp)} except json.JSONDecodeError: return {type: text, content: resp} def _execute_tool(self, name: str, arguments: dict): if name add: return {result: arguments[a] arguments[b]} if name get_weather: return {city: arguments[city], weather: 晴, temperature: 25} return {error: f未知工具: {name}}main.pyfrom agent import Agent if __name__ __main__: agent Agent() while True: user_input input(请输入你的问题输入 exit 退出: ) if user_input.lower() exit: break answer agent.run(user_input) print(f\nAgent: {answer}\n)这个示例中的_parse_response有意简化了协议解析逻辑。真实生产环境需要处理 OpenAI 标准的 function call 消息格式也就是 message 对象里带tool_calls字段。这里改成 JSON 文本解析是为了让说明更聚焦避免文章被大段 SDK 类型定义占据。3.4 提示词里的效率观你现在要的不是华丽而是“不出错”示例里的SYSTEM_PROMPT并没有使用复杂措辞只有三条原则必须调用工具、不要编造结果、回答要简洁。这是刻意设计。很多新手写提示词时会写一堆“你是一个优秀的助手”“请认真分析”“如果……请……否则……”这类内容。这些内容不是完全没有用但在 Agent 场景下它们会消耗 Token 并干扰模型的工具调用判断。更糟的是它们给模型留下了“解释权”而解释权正是 Agent 流程失控的根源。效率社会中的提示词也是一种库哈斯式设计减少装饰性语言保留功能流线。对结构化任务来说最好的提示词是自己不显眼的提示词它只需要把边界条件和动作约束说清楚。先让模型学会用工具再去打磨“人格化”的表达。4. 验证系统是否“高效”从日志、性能和稳定性三个维度看4.1 给 Agent 加日志没有可观测性一切效率都是幻觉库哈斯在设计建筑时会画人流流线图AI 工程的对应物是日志和追踪。没有日志你就不知道 Token 花在哪里、哪一步耗时最长、哪个工具返回了异常数据。给上面的 Agent 加上最小日志import time import logging logging.basicConfig(levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s) class TimedAgent(Agent): def run(self, user_input: str) - str: start time.time() result super().run(user_input) elapsed time.time() - start logging.info(input%s elapsed%.2fs result%s, user_input, elapsed, result) return result运行后你会看到类似输出2025-06-01 12:00:00 [INFO] input北京天气怎么样 elapsed4.32s result北京当前晴25度。这行日志的价值很大。它能让你在后续优化时回答三个问题用户输入是什么、系统花了多久、返回了什么。一旦生产环境出现问题这三条信息就是定位的第一现场。4.2 三种典型的“伪效率”现象第一种伪效率是“回答很快但一步错步步错”。模型在工具调用前生成了错误参数Agent 没有校验参数类型直接发给工具工具抛异常Agent 重试一次还是同样错误。速度很快但结果完全不可用。第二种伪效率是“步骤少但上下文超长”。开发者为了减少调用次数把整个历史对话一股脑发给模型。结果是单次调用耗时呈平方级上升Token 成本翻倍糟糕的是模型还会被无关历史干扰。第三种伪效率是“输出稳定但全是幻觉”。温度调低到 0 之后模型确实每次都输出同样的内容但如果它本身不知道答案它也会用同样一本正经的方式编造答案。低温度只能保证“稳”不能保证“真”。4.3 用测试用例代替拍脑袋判断验证 Agent 是否高效不应该靠“我觉得还行”而是要用一组固定测试用例跑回归。测试用例要覆盖领域内最常见的任务同时把输入、预期行为、允许的输出差异都写在表里。测试编号用户输入预期行为通过标准T001计算 1237 的和调用 add 工具输出 49不出现模型自算结果T002北京天气怎么样调用 get_weather 工具结果中不包含“我不知道”或编造的空气质量数值T003你好不调用工具直接文本回复输出存在且未触发任何工具调用T004计算 3.54.2 的和校验参数失败或明确提示明确告知参数不支持小数而不是静默截断T005连续问 5 个问题上下文顺序不混乱第 5 个问题能正确引用前面的历史信息建议把测试用例保存成 JSON 文件然后用 pytest 或简单脚本自动执行。这样每次修改提示词、调整参数、切换模型时都能在几分钟内获得一份质量回归报告。注意不要只验证“系统能启动”要验证“系统在异常输入下不会悄悄出错”。Agent 系统里静默错误比显式报错更危险。5. 生产环境中的效率禁欲成本、监控、缓存与模型选择5.1 成本效率Token 不是免费的调优前先记账学习环境里调大上下文窗口没有感觉生产环境里每次调用都是费用。一个典型例子把 128K 上下文窗口全塞满单次请求成本可能是小上下文请求的几十倍。更重要的是大模型对超长上下文的注意力并不均匀很多项目在长上下文上的实际表现并不比“摘要加检索”更好。成本优化有三个直接抓手。第一只发送必要的历史消息。可以在 Agent 内部维护消息摘要超过 N 轮后把旧消息压缩成摘要而不是直接丢弃或全量发送。第二使用输出 Token 上限。max_tokens不止是限制长度它还能防止模型陷入冗长循环或输出无意义的重复文本。推荐值需要根据业务判断但生产环境给一个硬顶总是对的。第三缓存常用的系统提示词和工具定义。虽然不同云厂商的缓存机制不同但把稳定内容放在消息头部、动态内容放在消息尾部能提高命中部分前缀缓存的概率。5.2 稳定性效率超时、重试和降级必须提前设计生产环境的大模型 API 不稳定是常态而不是异常。网络抖动、限流、服务端过载、模型推理变慢这些都会导致请求失败。Agent 代码里必须设计三层保护。第一层是超时每一次模型调用都必须有超时时间推荐值 30 到 60 秒具体要结合模型复杂性调整。没有超时意味着一次挂死的请求会一直占用线程池。第二层是重试对网络错误和 429 限流可以重试但必须使用指数退避。直接无限重试会把一次小故障放大成雪崩。第三层是降级模型不可用时有兜底响应。例如客服系统可以返回“服务暂时不可用请稍后再试”而不是让用户面对一个一直在加载的页面。import time from openai import OpenAI from config import BASE_URL, API_KEY client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) def call_with_retry(messages, retries3, base_delay1.0): for attempt in range(retries): try: resp client.chat.completions.create( modelqwen2.5:7b, messagesmessages, temperature0.2, max_tokens1024, timeout30, ) return resp.choices[0].message.content except Exception as e: delay base_delay * (2 ** attempt) print(f第 {attempt 1} 次调用失败: {e}, {delay}s 后重试) time.sleep(delay) raise RuntimeError(模型调用多次失败请检查服务状态)这段代码演示了一个通用重试骨架。生产环境需要把print替换成结构化日志并接入监控告警。超过重试次数后应该走降级逻辑而不是让调用方直接收到异常。5.3 模型效率不是模型越大越好而是越合适越好选择模型是一个需要权衡的决策。7B 量级的量化模型在普通电脑上就能运行延迟低、成本低但对复杂推理和长文本理解的能力有限。70B 以上的模型能力强但需要多张高性能 GPU部署和运维成本会指数上升。模型规模适合场景资源消耗延迟预期语言理解能力1B - 3B意图分类、实体抽取、简单问答CPU 可运行极低有限7B - 14B通用问答、工具调用、中等代码生成单张消费级 GPU低到中中等70B 以上复杂推理、长篇文章、高质量创作多张高性能 GPU中到高强常见项目的落地顺序是先用小模型跑通完整链路再评估质量缺口。如果小模型在测试集上的通过率已经达到业务要求就不必一味追求大模型。效率优化应该从“满足需求的最小资源”开始而不是从“最强模型”开始。6. 常见坑与排查链路现象、根因、检查方式、处理方案6.1 Agent 一直不调用工具而是自己编答案现象用户问“计算 1237”Agent 回复“123749”但日志里没有工具调用记录。模型可能是在“猜”答案而不是在“算”答案。根因提示词没有强调必须调用工具或者示例中没有给工具调用示范又或者模型本身对工具调用的指令遵循能力较弱。检查方式查看日志中 messages 是否包含 tool_calls 相关信息。缩小输入只发送一条 tool 请求观察模型输出。检查 SYSTEM_PROMPT 是否包含“必须调用工具”的明确约束。处理方案在提示词中加入“当问题匹配工具时必须先调用工具不要直接回答”的约束。给出一两条工具调用的 few-shot 示例。如果模型仍不调用换用对 function call 支持更好的模型。6.2 模型输出了合法 JSON但参数类型错误现象工具的a参数声明是 integer模型传了字符串12。代码里直接做加法结果是字符串拼接输出1237而不是49。根因模型没有严格遵循 JSON Schema或者代码没有做参数类型校验。检查方式打印_parse_response解析出来的 arguments 原始值。记录工具收到的实际类型。处理方案在_execute_tool里做类型转换和校验def _execute_tool(self, name: str, arguments: dict): if name add: try: a int(arguments.get(a)) b int(arguments.get(b)) except (TypeError, ValueError) as e: return {error: f参数必须是整数, 原始参数: {arguments}, error: {e}} return {result: a b}对于关键业务工具服务端要再做一次参数校验不能信任模型输出。6.3 连续对话后上下文越来越长响应越来越慢现象多轮对话从第 10 轮开始延迟明显增加甚至超出超时时间。根因Agent 把全部历史消息都塞进上下文消息长度随轮次线性增长模型推理时间也随之增长。检查方式统计每次请求发送的总字符数或 Token 数。查看代理日志中messages数组的长度。处理方案只保留最近 5 轮会话更早的消息用摘要替代。设置上下文最大 Token 数超出后触发截断或摘要。关键信息用户 ID、订单号、需求状态在 Agent 状态对象里单独保存不依赖历史消息记忆。6.4 超时和重试导致重复执行现象工具调用因为网络超时返回异常Agent 重试时工具又被执行了一次。如果这个工具是写库操作就会产生重复数据。根因重试逻辑没有做幂等保护。检查方式查看工具日志里同一个请求 ID 是否出现多次。处理方案工具调用必须传入幂等键例如request_id服务端通过幂等键去重。在 Agent 层生成请求 ID重试时复用同一个 ID不要让下游以为这是新请求。7. 最佳实践清单从隐喻回归工程纪律7.1 每个 AI 项目上线前都应该过一遍的检查项以下清单适合打印出来贴在工位上。每一项都是实际项目里踩过的坑。模型调用是否配置了超时默认超时是否过短或过长重试逻辑是否使用指数退避是否设置了最大重试次数工具调用是否做了参数类型校验是否校验了必填字段模型输出的 JSON 解析失败时有没有兜底路径上下文历史是否限制长度超出部分如何压缩关键业务工具是否有幂等保护是否记录了请求 ID、输入摘要、输出摘要、耗时和 Token 消耗是否准备了降级响应模型服务挂掉时用户看到什么是否做了成本估算同样的功能一天调用多少次单次多少钱测试用例是否能自动回归改提示词后能否快速发现质量下降这十条里如果有三条以上回答“没有”不要先考虑换更强模型先把基础的工程边界补齐。7.2 提示词管理的版本化实践提示词是会变化的而且变化频率往往比代码高。生产项目应该把提示词当成代码来管理放入 Git 仓库、有版本号、有评审记录、可以回滚。推荐目录结构prompts/ ├── system/ │ ├── agent_v1.txt │ ├── agent_v2.txt │ └── summarize_v1.txt ├── tools/ │ ├── add.json │ └── get_weather.json └── few_shot/ ├── tool_call_examples.json └── json_output_examples.json每次修改提示词后跑一遍 3.3 里的测试用例表。如果通过率下降就回滚到旧版本。通过率的变化比“感觉回答变聪明了”可靠得多。7.3 用“效率审计”对抗效率拜物教库哈斯不会满足于“机场吞吐量很大”这个结论他会问吞吐量背后是谁在付出代价AI 工程也一样。定期做一次效率审计问自己几个问题当前系统把时间省在哪里又把时间浪费在哪里Token 消耗最大的 10 个子流程是什么它们是否都必要是否有某些流程为了降低单次调用延迟而牺牲了整体正确性模型输出如果“稳定地错误”系统能识别出来吗当前的成本结构里真正产生用户价值的部分占多少比例这些问题没有标准答案但它们能让团队意识到效率不是目标而是手段。当效率手段开始反噬系统质量时就值得停下来重新设计。8. 库哈斯式隐喻的终点从效率机器回到问题解决者如果把 AI 系统比作库哈斯笔下的建筑那今天的很多大模型应用都很像“过度设计的机场”流程完备、吞吐高效、入口处挂着巨大屏幕欢迎每一位旅客但旅客真正想要的只是快速到达一个出口。流程越高效越容易让人忘记这个系统最初是为什么而建。在实际项目里这意味着三件事。第一先定义“什么算完成”。一个客服 Agent 的完成标准不是“把对话轮数减少到 1 轮”而是“用户问题得到准确解决”。如果减少轮数导致更多用户重复提问那这个优化就是负收益。把完成定义写在项目文档里每次效率优化都要对照这个标准评估。第二为 AI 系统留出“冗余空间”。库哈斯的设计里大空间和高密度并存。AI 系统也需要保留人工接管、异常兜底、数据备份的冗余能力。不要为了极致的 Token 效率删掉所有兜底逻辑那些看似“浪费”的日志、校验和降级代码才是系统能在生产环境存活下来的原因。第三把隐喻当成一面镜子。当团队陷入“模型不够强、要换更大参数”的焦虑时回到隐喻里想一想问题到底出在模型能力还是出在我们编写的流程很多项目的问题不在祭坛模型而在于祭司Agent 代码没有理解祈祷词提示词。这篇文章从库哈斯的建筑隐喻出发讨论了大模型时代的效率依赖现象然后落地到一套最小 Agent 工程实践。你可以把这里的代码当成一个“骨架工程”在此基础上扩展自己的工具、提示词和业务逻辑。下一步值得做的是把你手头最频繁的一个重复性任务用这个骨架实现成 Agent然后记录改进前后的时间消耗和质量变化。只有当你亲手把一个任务从“人工完成”变成“Agent 完成”并且能验证结果质量时你才算真正理解了大模型工程的效率逻辑。