如果你关注过去两年 AI 圈的大新闻，会记得一件事：王慧文顶着“带资进组”的标签下场做 AI 大模型，成为行业里最受关注的创业者之一。他的做法很直接：不聊概念，先看技术路线，再组团队，再把钱和资源压到模型本身。当时很多人把这理解为“又一个想炼大模型的人”，但如果把时间线拉长，你会发现更重要的不是那一次创业本身，而是他身后资金走向的变化——从早期押注大模型基础设施，到后来把目光放到了 AI Agent 这个更贴近落地层的方向。
这篇内容要讨论的不是八卦，而是一条明确的技术与投资主线：当大模型进入“集体涨价还是免费开放”的争议期，当基础模型的格局逐渐稳定，真正值得技术人和团队关注的价值增量在哪里。我的判断是：接下来几年，AI 竞争的主战场会从“模型能力”转向“Agent 效果”。模型层越来越像水电煤，而 Agent 层才是决定产品能不能被用户用起来的关键。本文会从技术架构、开发流程、落地验证和工程风险四个方面展开，帮你理解为什么这条主线值得关注，以及作为开发者怎么跟进。
1. 从大模型到 AI Agent，投资逻辑发生了什么变化
先理清一个容易被误解的问题：大模型和 AI Agent 不是同一个层次的东西，也不是替代关系。大模型是“大脑”，AI Agent 是“会使用大脑完成任务的助手”。过去资本讨论的是“谁的模型参数更大、推理更强”，现在讨论的更多是“谁能让模型在具体任务里真正闭环”。
1.1 基础设施红利期正在收窄
大模型创业最热的那一两年，核心叙事是“炼大模型”。训练千亿参数模型需要算力、数据、算法工程能力，这决定了它是一个高资本密度赛道。但随着开源社区和头部厂商把模型能力快速拉平，闭源模型和开源模型之间的距离在缩小。对绝大多数创业团队来说，从零训练一个大模型已经不是理性选择，成本高、周期长、回报不确定。
从公开信息看，王慧文早期的选择和这个判断是一致的：他愿意做大投入、做长期技术投入，方向也符合当时行业公认的“模型能力决定上限”逻辑。但模型的“上限”和“可用性”之间还有很长的距离。今天行业里更稀缺的不是又一个大模型，而是能把模型用起来、围绕实际场景做成产品的工程化能力。
1.2 价值判断从“模型参数”转向“任务闭环”
一个很直观的对比：过去你问一个 AI 团队，你们的优势是什么？回答往往是“我们的模型在某个榜单上排名靠前”。现在你问同样的问题，头部团队更可能回答“我们的 Agent 在客服、代码生成、数据分析等具体任务上，能把错误率降到自己可控的范围”。
这个变化背后其实是评估体系的变化。模型榜评测的是静态能力，而业务场景要的是动态效果。一个模型单次回答再专业，如果它在多轮对话中忘记上下文、调用工具时选错参数、生成结果后无法自我纠错，那它离“能用”还差很远。AI Agent 恰恰是解决这个差距的技术方案：它把模型的单次能力串成一条完整的工作流，让模型在目标、计划、工具、记忆、执行、验证这几个环节里循环起来。
1.3 大模型与 Agent 的投入产出比差异
从商业角度看，大模型是典型的“高固定成本、低边际成本”生意。前期训练投入巨大，训练完成后每次调用的成本虽然存在，但相对可控。AI Agent 则是“中等固定成本、持续迭代成本”的生意。它不需要你重新训练模型，但它需要大量时间做提示词工程、工具编排、流程调试和异常兜底。
这带来一个结果：大模型赛道的玩家数量会快速收敛，而 Agent 赛道的玩家数量会持续增加。因为 Agent 层的核心壁垒不是资金规模，而是对具体业务的理解和工程执行力。这也是为什么现在更多的创业机会和资本注意力都在往下游走。
2. AI Agent 核心概念：它到底解决了什么问题
很多开发者对 AI Agent 的理解还停留在“给模型加几个工具调用”。这种理解不能算错，但它把 Agent 简化成了一个技术组件。实际上，AI Agent 是一个把模型、感知、规划、行动、记忆串联起来的系统架构。
2.1 Agent 与传统 API 调用的区别
传统 API 调用的流程是：用户请求 → 程序处理 → 返回结果。逻辑是死的，路径是预先写好的。AI Agent 的流程是：用户目标 → 模型理解 → 模型生成计划 → 选择工具 → 执行动作 → 观察结果 → 决定下一步。逻辑是动态的，路径是模型根据上下文推理出来的。
用一个实际例子说明。假设你要做一个“自动整理周报”的功能。
传统方式：
# 伪代码：传统 API 调用 user_input = "帮我整理本周工作周报" data = query_database("select * from tasks where user_id = ? and week = ?") report = generate_report(data) return reportAgent 方式：
# 伪代码：Agent 方式 agent = create_agent( llm=model, tools=[query_database, generate_report, send_email] ) result = agent.run("帮我整理本周工作周报，看一下有哪些任务还没完成，然后发给主管")传统方式要求你把每一种可能都写成代码分支。Agent 方式只需要你给模型一个目标、一组工具和必要的边界条件，剩下的路径由模型自己规划。这也是 Agent 能解决“长尾、多变、非结构化”任务的原因。
2.2 Agent 的组成模块
一个完整 AI Agent 通常由五个模块组成：
| 模块 | 作用 | 类比 |
|---|---|---|
| 大模型（LLM） | 理解意图、生成计划、产生回复 | 大脑 |
| 规划器（Planner） | 把目标拆解成步骤 | 项目经理 |
| 工具集（Tools） | 访问外部数据和执行动作 | 手脚 |
| 记忆（Memory） | 保存上下文信息和历史结果 | 工作笔记 |
| 执行器（Executor） | 控制循环、调度模块、处理异常 | 流程引擎 |
这里面最容易误解的是记忆。很多开发者以为把聊天记录存下来就是记忆，其实 Agent 的记忆分两层：短期记忆负责当前任务的上下文，长期记忆负责跨任务的偏好和知识沉淀。没有长期记忆的 Agent 只能做一次性任务，有了长期记忆的 Agent 才能在多次交互中不断优化表现。
2.3 Agent 的三种主流工作模式
- 单 Agent 模式：一个模型实例负责全部流程。适合任务链路清晰、工具数量不多的场景。
- 多 Agent 协同模式：多个 Agent 分别承担不同角色，比如一个写代码、一个做测试、一个做审查。适合复杂工程任务，但需要处理 Agent 之间通信和状态同步的问题。
- 人机协同模式：Agent 负责执行和筛选，关键节点由人来确认。适合风险敏感场景，比如自动交易、医疗建议。
从实际落地看，单 Agent 模式最容易起步，多 Agent 模式的上限最高，但工程复杂度也最高。不建议一上来就追求多 Agent，很多问题单 Agent 优化提示词和工具设计就能解决。
3. 为什么从大模型到 Agent 会成为投资与开发共识
这一节把问题往前推一步：为什么不是“模型能力继续增长”而是“Agent 落地”成为新共识？这不是某个人的偏好，而是技术演进的必然。
3.1 模型能力进入“平台期”与“应用爆发期”
一个技术方向的吸引力，取决于它的边际收益。大模型基础能力的提升虽然还在继续，但对大多数应用开发者来说，GPT 级别的模型和开源的顶尖模型在日常任务上的差距已经不足以成为决策的唯一因素。反而是“怎么用”的问题更痛：模型经常产生幻觉、工具调用不稳定、多轮对话容易偏题。这些问题不是模型参数能直接解决的，而是需要 Agent 架构来解决。
观察最近两年的技术热点也能看出这个趋势：Agent 框架、Agent 互操作协议、模型上下文工程、工具调用优化，这些方向的热度明显上升。资本和开发者都在做同一件事——围绕模型构建外围能力，而不是再竞争谁的基础模型更强。
3.2 从“AI 能用”到“AI 好用”的价值跃迁
大模型刚出现时，大家最兴奋的是“AI 能写代码、能写文案、能回答问题了”。这种兴奋持续了一段时间，然后回归冷静：AI 能写，但不能保证写对；AI 能做，但不能保证做完。要想让它保证结果质量，就得给它流程、给它工具、给它检查机制。
AI Agent 正是这个“流程化封装”的方案。它让 AI 不再是“回答一个问题的聊天框”，而是“完成一件任务的工作流”。这种改变对用户的价值是直接的：聊天框只能给建议，Agent 能交付结果。资本追逐 Agent，本质上是在追逐“AI 从工具变成助理”这个产品机会。
3.3 开源与闭源模型的竞争推动了 Agent 层繁荣
还有一个容易被忽视的因素：开源模型的繁荣。当 Llama、Qwen、DeepSeek 等开源模型的能力越来越强，开发者就能用相对低的成本拿到高质量模型底座。这改变了应用层的成本结构——过去调用大模型 API 是一笔持续成本，现在可以在本地或私有化环境部署开源模型，把推理成本降下来。
本地部署开源模型这件事，本身就和 Agent 开发强相关。原因是 Agent 应用往往需要大量调用模型，如果全部走云端 API，成本压力会很大。而本地部署方案（比如用 Ollama 这一类工具）可以把模型的调用成本降到可忽略的水平，让开发者可以放开手去调试 Agent 流程。这也是为什么现在很多 Agent 教程会从“本地部署一个模型”开始讲起。
4. AI Agent 开发落地：从模型部署到框架选型
进入实操层面。如果你是一个想要切入 AI Agent 方向的开发者，第一步不是写代码，而是先把技术栈选型弄清楚。
4.1 模型层：本地部署与云端 API 怎么选
选择原则很简单：
- 追求效果和开发速度，选云端大模型 API，比如 Claude、GPT 系列、国内主流厂商的 API。
- 追求成本和隐私可控，选本地部署开源模型，用 Ollama 或 vLLM 这类工具。
- 混合方案：开发阶段用云端 API 快速迭代，上线后用本地模型降成本。
实际项目中，比较稳妥的做法是先跑通云端方案，确认 Agent 的逻辑没问题，再评估是否切换本地模型。因为 Agent 调试的复杂度已经很高，如果模型层再不稳定，问题排查会非常痛苦。
下面给出一个基于 Ollama 的最小部署过程（版本以实际项目为准，本文演示通用思路）。
# 1. 安装 Ollama（支持 macOS / Linux / Windows） curl -fsSL https://ollama.com/install.sh | sh # 2. 下载并启动一个开源模型 ollama pull qwen2.5:7b ollama serve启动后，Ollama 会在本地提供一个兼容 OpenAI 格式的接口，默认地址是http://localhost:11434。你可以直接把它当作模型后端来使用。
4.2 Agent 框架层：怎么选适合自己的框架
现在 Agent 框架非常多，但核心能力差别不大，主要看你要解决什么问题。
- LangChain / LangGraph：功能全，生态丰富，适合有一定工程能力的团队，但抽象层级多，学习曲线较陡。
- Dify：偏产品化，可视化编排，适合快速搭建 Agent 应用，也适合非深度技术背景的人。
- n8n：偏自动化工作流，适合把 Agent 嵌入到现有业务系统里做流程串联。
- 自研框架：如果你的业务有强定制需求，自研反而可控。最小实现并不复杂：一个大模型接口 + 工具注册表 + 循环控制逻辑即可。
我的建议是：第一次实践不要过度依赖重量级框架。先理解 Agent 的循环逻辑，再决定要不要引入框架。框架是用来提高效率的，不是用来掩盖理解缺失的。
4.3 Agent 与 Skill、插件的关系
很多开发者会把 Agent、Skill、插件这三个概念混在一起。简单区分：
- 插件（Plugin）：为模型或 Agent 增加一个具体能力，比如“天气查询插件”。
- Skill：是一组为完成特定任务准备好的提示词、工具调用序列和示例流程，更偏“怎么用”的经验封装。
- Agent：是具备规划、记忆、工具调用能力的整体系统。它可以加载多个 Skill，也可以调用多个插件。
一句话总结：插件解决“能做什么”，Skill 解决“怎么做得好”，Agent 解决“怎么把任务完成”。
5. 完整示例：用 Python 实现一个最小可运行 AI Agent
为了让概念落地，我编写了一个最小可运行的 Agent 示例。它不依赖任何重型框架，只使用标准库加一个 OpenAI 兼容接口。这个示例包含三个核心部分：工具定义、工具调度、循环执行。
5.1 环境准备
需要openaiPython 库（用于调用兼容接口），可以用 pip 安装：
pip install openai如果你使用的是 Ollama 本地服务，无需额外配置 API Key，只要后端在运行即可。
5.2 完整代码
创建一个文件minimal_agent.py：
# 文件路径：minimal_agent.py import json from openai import OpenAI # 连接本地 Ollama，或替换为你的云端 API client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务可填写任意占位字符串 ) MODEL = "qwen2.5:7b" # 1. 定义工具：返回给模型的 JSON Schema TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名，例如北京"} }, "required": ["city"] } } }, { "type": "function", "function": { "name": "calculate", "description": "执行四则运算", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，例如 1+2"} }, "required": ["expression"] } } } ] def run_tool(name: str, arguments: dict) -> str: """实际执行工具，返回字符串结果""" if name == "get_weather": # 真实项目中应调用天气服务，这里返回模拟数据 city = arguments.get("city", "未知城市") return json.dumps({"city": city, "weather": "晴", "temperature": 26}, ensure_ascii=False) if name == "calculate": # 安全的四则运算，仅演示。生产环境不要直接用 eval expr = arguments.get("expression", "") try: result = eval(expr, {"__builtins__": {}}, {}) return json.dumps({"result": result}) except Exception as e: return json.dumps({"error": str(e)}) return json.dumps({"error": f"未知工具: {name}"}) def agent_run(user_input: str, max_steps: int = 5): """Agent 主循环：模型自主决定是否调用工具""" messages = [ {"role": "system", "content": "你是一个智能助手，可以调用工具完成用户任务。"}, {"role": "user", "content": user_input} ] for step in range(max_steps): response = client.chat.completions.create( model=MODEL, messages=messages, tools=TOOLS ) msg = response.choices[0].message messages.append(msg) # 如果模型没有要求调用工具，说明回答结束 if not msg.tool_calls: return msg.content # 依次执行模型要求的每个工具调用 for tool_call in msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f"[step {step+1}] 调用工具: {fn_name}, 参数: {fn_args}") tool_result = run_tool(fn_name, fn_args) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": tool_result }) return "达到最大步骤数，任务未能在限定步数内完成。" if __name__ == "__main__": print(agent_run("今天北京天气怎么样？顺便帮我算一下 123*456 等于多少"))5.3 代码关键逻辑说明
这个示例虽然不到一百行，但覆盖了 Agent 的核心闭环：
- 模型通过
tool_calls决定是否调用工具，以及调用哪个工具。 - 执行器拿到工具调用请求后，调用真实的
run_tool函数。 - 工具执行结果以
role: "tool"消息回传给模型，模型根据结果生成最终回答。
当模型第一次收到用户消息时，它可能会输出两个工具调用（天气查询和计算）。执行器依次执行后，把结果追加到消息列表，模型再基于这些结果生成最终回复。
这里真正需要注意的是消息格式。OpenAI 兼容接口要求工具结果必须通过tool_call_id和原工具调用关联，否则模型无法理解结果对应哪个请求。
6. 运行验证与常见问题排查
6.1 启动与执行
确保 Ollama 服务已运行：
ollama serve然后在另一个终端执行：
python minimal_agent.py如果你配置的是云端 API，把base_url和api_key改成你自己的内容即可，代码逻辑完全不需要变。
6.2 预期输出
运行后，你应该会看到类似下面的过程：
[step 1] 调用工具: get_weather, 参数: {'city': '北京'} [step 2] 调用工具: calculate, 参数: {'expression': '123*456'} 今天北京天气晴，气温26摄氏度。123乘以456等于56088。只要模型能够正确识别出需要调用两个工具，并且最终把两个结果汇总成自然语言回答，就说明最小 Agent 链路已经跑通。
6.3 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型不调用工具 | 模型版本不支持 function calling，或提示词未引导 | 查看返回的 message 中是否有 tool_calls 字段 | 更换支持工具调用的模型，或在 system 提示词中强调“需要调用工具时务必使用” |
| 工具结果未回传 | tool_call_id 不匹配 | 检查 messages 中 tool 消息是否包含正确的 tool_call_id | 使用响应原样返回的 tool_call_id |
| 本地模型推理慢 | 模型体积大或 CPU 推理 | 观察 llama.cpp 日志，确认是否使用 GPU | 换更小模型，或配置 GPU 加速 |
| 工具执行结果被忽略 | 模型对工具返回格式理解不足 | 打印工具返回内容，检查是否被截断 | 工具返回内容尽量简洁，重要信息放前面 |
| 循环次数过多 | 模型反复调用工具无法收敛 | 打印每次调用的工具与参数，观察是否出现重复 | 提高 max_steps，并在提示词中要求“如果已获得足够信息就结束” |
第一次跑 Agent 遇到问题不要慌，排查顺序是：先看模型有没有输出 tool_calls，再看工具有没有执行成功，最后看工具结果有没有正确回传。百分之八十的问题出在这三个环节的连接上。
7. Agent 落地工程实践：安全、性能与可维护性
当一个 Agent 从演示项目走向生产环境，要考虑的问题会突然变多。这里整理几个最关键的工程实践方向。
7.1 给 Agent 配置最小权限
Agent 能调用工具，就意味着它能执行动作。如果一个 Agent 的代码生成工具能访问生产数据库，那模型一旦被提示词注入或产生误判，后果会很严重。生产环境中的原则是：每个工具只授予完成业务所需的最小权限，不要让 Agent 拥有“万能钥匙”。
举个例子：如果 Agent 只需要查询订单，那就给它一个只读数据库账号，不要给它写权限，更不要给它管理权限。如果 Agent 需要操作文件，那就限制在特定沙箱目录内，禁止访问系统敏感路径。
7.2 工具调用要做参数校验和沙箱隔离
模型生成的参数不一定合法。比如示例里的calculate工具，直接使用eval是一个危险行为——生产环境绝对不能这么写。应该使用安全的表达式解析库，或者用 AST 方式校验后再执行。凡是 Agent 要调用的工具，都要把它当作“用户输入”来处理，做边界校验、超时控制、异常捕获。
对于需要执行代码的 Agent，隔离是必须的。推荐的做法包括：容器隔离、云函数沙箱、专用子进程加资源限制。总之，不要让 Agent 的代码能力直接运行在你的主服务进程里。
7.3 引入可观测性
Agent 的推理过程是不确定的，一旦出错，定位问题会比传统代码困难得多。生产环境必须记录以下信息：
- 用户输入和系统提示词。
- 模型每一步的完整输出（包括 tool_calls）。
- 工具调用的参数和返回结果。
- 每一轮的时间消耗和 token 消耗。
- 最终结果和用户反馈。
有了这些日志，你才能在 Agent 出错时回放整个过程，找到是哪一步导致结果偏差。
7.4 成本控制与性能优化
Agent 应用的一个特点就是模型调用次数多。一个简单任务可能就要调用两三次模型，复杂的任务可能达到几十次。成本控制不只是换便宜模型，更重要的是减少无效调用。
常见优化手段包括：
- 缓存高频问题的结果，避免重复调用。
- 用小型模型做意图识别，只有复杂任务才调用大模型。
- 设置单任务的 max_steps 上限，防止 Agent 陷入死循环浪费 token。
- 对工具返回做压缩，减少传给模型的上下文长度。
7.5 从 Demo 到生产的团队协作流程
Agent 开发和传统后端有一个区别：它需要更频繁地调试“模型行为”，而不只是调试“代码逻辑”。建议团队建立两条协作规范：
- 提示词版本管理：把系统提示词当作代码一样管理，记录每次修改的动机和效果，不要直接在线上改提示词。
- 回归测试集：准备一组覆盖核心场景的测试用例，每次改动提示词或 Agent 逻辑后，都跑一遍回归测试，观察结果退化情况。
这样做的目的是让 Agent 的“玄学”部分可控。模型行为确实有不确定性，但通过测试集和版本管理，你可以把不确定性限制在可接受范围。
8. 大模型到 Agent 趋势对开发者的影响
站在开发者的角度，这个趋势到底意味着什么？在我看来，最核心的变化是能力栈重心的迁移。
8.1 开发者需要的技能结构正在变化
过去两年，掌握“调用大模型 API”已经不能算核心竞争力，因为调用本身太简单了。真正稀缺的是三类能力：
- 流程拆解能力：把一个复杂业务拆成 Agent 能执行的任务序列，设计好每个任务的输入输出。
- 工具设计能力：为 Agent 设计清晰、鲁棒的 Tool API，让模型容易理解、容易调用、不容易出错。
- 评测与调试能力：建立可靠的评测集，能快速定位 Agent 在哪个环节出现问题，并系统性地改进。
这三类能力都不是算法岗专属，反而是工程思维强的人更有优势。这也是为什么很多后端工程师转 Agent 开发比较顺畅。
8.2 Agent 开发的“坑”比想象中多
很多新手容易犯一个错误：以为 Agent 框架能包办一切，只要把工具注册进去就能自动干活。实际上，框架只是提供了基础设施，真正决定 Agent 质量的是你对任务的理解深度。同一个工具，不同的人注册进去，写出的描述不同，模型调用它的准确率就会不同。
工具描述要写清楚三件事：工具是干什么的、什么时候应该用它、参数怎么填。描述太简单，模型不知道该不该调用；描述太啰嗦，模型容易误解重点。这需要大量实验和迭代。
8.3 未来方向：从单 Agent 到多 Agent 生态
虽然我建议初学者从单 Agent 入手，但整个行业的发展方向确实是多 Agent 协同。多 Agent 的优势在于：每个 Agent 可以专注于一个领域，通过相互调用完成复杂任务，就像一支团队而不是一个全能的个体。
多 Agent 的工程复杂度主要体现在通信协议、任务分配、状态管理和冲突消解上。如果未来出现更成熟的 Agent 互操作标准，多 Agent 的开发门槛会明显降低。作为开发者，现在可以先积累单 Agent 的深度经验，等协议成熟后再平滑切换到多 Agent 架构。
9. 结论与行动建议
回到最初的问题：为什么王慧文为代表的资本眼光从大模型转向了 AI Agent？更准确的表述是，不是放弃大模型，而是把筹码加到了大模型之上的应用层。模型的底座价值仍然存在，但增量价值正在向上游流动，流动到 Agent 这一层。
对开发者来说，现在的局面其实很好：你不一定需要训练模型，甚至不一定需要付费使用云端模型，只靠开源模型加合理的 Agent 架构，就能做出有真实用户价值的产品。门槛比过去低了，但工程要求比过去高了。
如果你打算开始实践，建议按这个路线走：
- 先用本地部署或云端 API，把一个模型跑通。
- 不加任何框架，手动实现一次“模型 → 工具调用 → 结果回传 → 最终回答”的循环（可以参考本文的
minimal_agent.py）。 - 跑通后，引入一个 Agent 框架，尝试做一个具体业务场景，比如自动报表、代码审查助手、客服工单分类。
- 为你的 Agent 建立评测集和回归测试，开始关注效果稳定性和成本。
- 再往深走，探索长期记忆、多 Agent 协作和 Agent 互操作协议。
AI Agent 的方向足够大，也足够新，现在入局不算晚。关键是别停留在概念讨论上，尽快跑通一个最小闭环，然后用真实业务去打磨它。AI 行业从来不缺少概念，缺少的是能把概念变成稳定产品的人。
