智能体开发的荒谬现状：我所见证的"气象帝国"与上下文工程的被忽视之道
当核电站给手电筒充电：我眼中的智能体开发乱象
上周，我又一次坐在一家AI创业公司的会议室里，面对着投影屏幕上那张复杂得令人眩晕的系统架构图。箭头纵横交错，模块层层堆叠，各种时髦的技术术语密密麻麻地填满了每一个角落：多智能体协作系统、向量数据库、深度检索引擎、元认知反馈循环、知识图谱增强...
我强忍着翻白眼的冲动，礼貌地问道："这个系统主要是用来解决什么问题的？"
"哦，"对方的CTO笑着回答，"这是我们的订单查询助手，可以...。"
没等他说完, 我差点把嘴里的蜜雪冰城喷出来。
"气象帝国"：我亲眼目睹的工程浪费
一个公司（为保护当事人以及利益关系，就叫它"气象帝国"吧）的团队配置相当豪华：2名全职后端工程师，1名机器学习专家，3名前端开发，还有一位从某知名AI实验室挖来的首席科学家。他们花了整整两个月时间，构建了这个所谓的"革命性天气智能体"。
CTO滔滔不绝地向我介绍他们的"创新架构"：
"我们实现了自研的MCP架构——模块化认知程序，"他自豪地说，"我们的核心——四层深度语义理解引擎，能精确捕捉用户的真实意图；后端连接了某某气象数据源和三个历史天气数据库..."
他说了足足25分钟，期间我数了一下，PPT翻了37页。
终于，演示环节到了。
他清了清嗓子，对着麦克风说："北京今天天气怎么样？"
系统运转了大约3秒钟（据说是因为要经过多层推理和数据融合），最后回答：
"北京今天多云转晴，气温22到27度，湿度45%，有轻微污染，建议适量户外活动。"
就...这？
我忍不住问："你们知道用OpenAI的function calling加上一个天气API，大概10行代码就能实现这个功能吧？"
会议室里的空气瞬间凝固。
令人窒息的工程资源浪费
当我后来了解到这个项目的具体细节时，我更是震惊了：
- 他们写了超过20,000行代码
- 部署了4个微服务
- 使用了3个不同的数据库系统
- 建立了自己的向量检索引擎
- 甚至还打算训练一个小型语言模型来"优化"天气的描述效果
更令人窒息的是，这个项目耗费了约420个人天——也就是说，如果一个工程师全职工作的话，需要大约一年半的时间。
而实际上，一个简单的解决方案可能是这样的：
def get_weather(location, date):
# 调用OpenWeather API
response = requests.get(f"https://api.openweathermap.org/data/2.5/weather?q={location}&appid={API_KEY}")
return response.json()
# LLM工具定义
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定地点的天气信息",
"parameters": {...}
}
}
]
# 一个好的提示模板
prompt = """你是一个友好的天气助手。当用户询问天气情况时，使用get_weather函数获取数据，
然后以自然、友好的方式回答。不要编造数据。如果你不确定或需要更具体的信息，
礼貌地询问用户。"""
# 就是这样！大概一小时就能搞定
很难想象如果我向CTO展示这个简化方案时，他的表情会多么复杂得令人心疼。但很快，我想到了一个驳我的理由：
"但是我们的系统可扩展性更强！未来我们还要加入旅游推荐、穿衣建议、户外活动规划..."
我忍不忍心说："这些功能同样可以通过简单的工具函数和好的提示工程来实现，不需要这么复杂的架构。" 但我必须得说, 不能看着大家路子走歪.
PS: 事实上, 关于大模型这块儿, 目前谁也不敢说自己的路子就是对的, 毕竟是新出来的玩意儿,
专家和小白之间差距不大。
为什么会出现这种"宏伟工程病"？
思考了很久，我认为这种现象背后有几个深层次原因：
-
投资人驱动的复杂性：简单方案看起来"没有技术壁垒"，不容易融资。复杂架构图则能给人一种"高深莫测"的印象。
-
工程师的自我实现欲：承认"我们只需要调用几个API"对很多工程师来说是种打击。构建复杂系统则能满足创造欲和技术表现欲。
-
跟风心态：当行业充斥着"多智能体系统"、"认知架构"等概念时，简单方案反而显得"不专业"。
-
对LLM能力的低估：很多团队仍然把LLM当作"只会聊天的模型"，没有真正理解它通过上下文工程能发挥的强大能力。
最讽刺的是，那些投入巨大资源构建复杂系统的团队，往往交付的产品体验并不比简单解决方案好。相反，复杂系统通常响应更慢，维护成本更高，出错概率更大。
上下文工程：被严重低估的"平民神器"
在智能体开发的喧嚣中，有一项核心技能被严重忽视了：上下文工程（Context Engineering）。
什么是上下文工程？简单来说，就是设计和优化输入到LLM的上下文信息，包括提示（Prompts）、示例、知识和工具定义等，使模型能够产生符合预期的输出。
上下文工程的核心要素
-
提示工程：构建清晰、结构化的指令，引导模型理解任务需求和期望行为。
-
工具定义：明确定义模型可以使用的工具（如API调用、函数等），包括它们的功能、参数和使用条件。
-
知识组织：将必要的背景知识、业务规则和约束条件结构化地呈现给模型。
-
示例设计：提供输入-输出的示例对，帮助模型理解预期的行为模式。
-
对话流程设计：规划用户与智能体交互的各种路径和处理方式。
为什么上下文工程如此强大？
我亲眼见证了上下文工程的神奇威力。去年，我用一个精心设计的提示模板和三个简单函数，在两天内搞定了一个客户原计划需要三个月的"智能客服"项目。
这个提示模板大概是这样的：
你是一位专业的客服助手，负责解答关于[产品]的问题。
你的沟通应当：
1. 专业但友好，避免过于技术化的术语
2. 简洁明了，优先回答用户的核心问题
3. 在不确定时，使用available_info工具查询信息库
4. 在需要检索订单信息时，使用check_order_status工具
对于以下场景，请遵循特定指南：
- 退款请求：表示理解，但引导用户使用官方渠道
- 技术问题：先询问基本信息（设备类型、软件版本等）
- 投诉：表示歉意，不争辩，寻求解决方案
记住，你的目标是高效解决用户问题，提供优质体验。
就是这样一个模板，加上几个简单函数（查询产品信息、检查订单状态、记录客服对话），构成了一个完全可用的客服智能体。没有复杂的多智能体协作，没有深奥的认知架构，没有花哨的记忆管理系统。
客户在测试后惊讶地说："这比我们之前那个耗资百万的系统表现还好！"
上下文工程的威力在哪里？
上下文工程之所以如此强大，是因为现代LLM本身就是强大的推理和执行引擎。它们天生具备：
- 语义理解能力：能够理解复杂指令和上下文
- 推理能力：能根据给定信息进行逻辑推导
- 工具使用能力：能判断何时以及如何使用提供的工具
- 自适应能力：能根据对话历史调整响应方式
我们需要做的，不是重新发明轮子，而是充分利用这些能力，通过优秀的上下文设计将它们引导向我们需要的方向。
智能体开发的理性之路
作为一个在AI领域摸爬滚打多年的从业者，我想对正在构建智能体的团队提出几点建议：
1. 从最小可行产品开始
先用最简单的方法实现核心功能，看看效果如何。你会惊讶地发现，很多时候，一个好的提示模板和几个工具函数已经能满足90%的需求。
2. 只在必要时增加复杂性
只有当简单方案确实无法满足需求时，才考虑引入更复杂的架构。每增加一个组件，都要问自己："这真
浙公网安备 33010602011771号