林俊旸前千问负责人回来了。新公司方向直接打出了 Agent 这个关键词腾讯跟投。这条消息在 AI 开发者圈的关注点和普通创业新闻不太一样——它同时把大模型基座、Agent 应用、开源生态商业化三个方向的人拉到了同一张讨论桌上。这篇文章不聊人物八卦重点拆三件事第一这条新闻释放了什么样的技术信号第二Agent 开发现在的技术底座到底长什么样千问系开源模型为什么特别适合做 Agent 切入点第三如果你想跟着这条路线动手验证最先应该跑通的几个环节是什么。文章会给出一套通用可执行的本地模型部署、Agent 最小骨架、接口调用和批量任务设计示例。需要先说清楚由于林俊旸新公司的具体产品尚未公开文中所有代码都是面向通用 Agent 开发场景的模板不是新公司产品的使用说明。你可以先把这套流程跑通等官方产品发布后再做替换。1. 事件核心信息速览维度信息核心事件前千问负责人林俊旸创业新公司方向为 Agent投资方动态腾讯跟投技术关键词千问、Qwen、Agent、开源大模型、本地部署、工具调用关注人群大模型开发者、Agent 应用开发者、关注开源模型的团队材料边界公司名称、产品形态、具体融资额和估值需以官方信息为准这个事件值得关注不是因为“又一个 AI 创业者拉了融资”而是因为林俊旸此前的背景在千问。千问是阿里开源的大模型系列在开发者社区里的使用率一直很高。一个亲手参与验证过开源大模型路线的人转身去做 Agent这个动作本身就说明Agent 不再只是 Demo 概念而是已经值得一线技术负责人投入的方向。对普通开发者来说这条新闻还有一个实用含义千问系开源模型做 Agent 的路径已经非常成熟。不管新公司最后做什么产品技术底座大概率还是开源模型、工具调用、任务编排这套体系。你现在就可以把这套体系跑通。2. 林俊旸是谁千问为什么重要关于林俊旸公开信息中的关键身份是“前千问负责人”。千问系列模型是阿里云开源的大模型家族覆盖了从 0.5B 级别的小参数模型到大规模模型的多个尺寸包含 Base、Instruct 等版本。Qwen2.5、Qwen3 等后续版本在 HuggingFace 和各类模型下载平台上有很高热度是国内外社区中覆盖面极广的开源中文大模型之一。千问为什么在开发者社区这么重要核心不是某一个模型的单项指标而是生态完整度。第一模型尺寸覆盖广。小参数模型可以在 CPU 或低显存显卡上运行大参数模型可以部署在高性能服务器上。开发者可以根据自己的硬件条件选择合适版本不用一上来就上企业级 GPU。第二配套工具链成熟。Ollama、LM Studio、llama.cpp、vLLM、Transformers 等主流推理框架都支持 Qwen 系列模型GGUF 量化版本也很多。这意味着本地部署的门槛很低普通人用一台带显卡的电脑就能跑。第三社区资料多。Qwen 系列在模型微调、function calling、多模态识别、代码生成、Agent 工作流等方面都有大量公开案例。遇到问题搜索一下基本都能找到类似的排错记录。林俊旸从千问走出来创业最大的价值不是“又一个 AI 创业者”而是他太了解开源模型开发者想要什么了。如果新公司做 Agent 产品大概率会把开源社区的体验、文档完整度、工程化能力放在很高优先级。这也是为什么说这条创业新闻值得继续跟踪因为它的产品形态可能会直接影响未来 Agent 开发者的工具选择。3. Agent 是一个赛道信号为什么创业公司要做 Agent先把 Agent 的定义说清楚。大模型 Agent中文常叫智能体核心能力是让模型不再只是“对话”而是能自己规划任务、调用工具、执行动作、观察结果、调整方案最终完成一个相对复杂的目标。举例来说普通聊天机器人只能回答“北京今天的天气怎么样”。Agent 则可以把“帮我安排一份北京三日游行程包含景点、餐厅、交通和天气提醒”这个任务拆解成搜索资料、对比方案、生成日程、调用日历工具等子任务然后逐个执行。Agent 和 ChatBot 的本质区别在于是否闭环。“对话”是单轮交互Agent 是多轮循环模型输出决策调用工具工具返回结果模型再根据结果决定下一步动作。这个循环越稳Agent 的可用性越高。为什么林俊旸这类大模型基座团队的人会选择 Agent 创业逻辑其实很清晰。模型层格局基本定型。开源模型像 Qwen、Llama 等已经覆盖了绝大多数能力需求继续做通用基座模型的边际难度和成本都非常高。而 Agent 是模型能力真正落到业务场景的方式它处在应用层离用户近离付费场景近对“懂模型又懂工程”的团队来说是当前最确定的落地方向。腾讯跟投这个动作从技术角度看也有信号意义。平台方需要 Agent 生态。Agent 要大规模运行离不开模型服务、云计算资源、应用分发渠道和数据合规体系。投资一个由前千问负责人创立的 Agent 公司等于同时押注了技术团队和 Agent 赛道本身。4. 千问系模型在 Agent 开发中的技术底座一个 Agent 系统不是一个模型而是由多个模块组成的软件系统。理解这一点才能理解为什么千问系模型适合作 Agent 的技术底座。一个最小可用的 Agent 系统通常包含以下模块。模块职责常见技术选型模型服务提供推理能力理解任务并输出决策Ollama、vLLM、LM Studio、云端 API工具调用让模型可以执行搜索、查库、操作业务系统Function Calling、工具脚本、OpenAPI记忆保存多轮对话和任务执行过程Redis、向量数据库、SQLite任务编排把任务拆解成步骤并控制流转顺序LangGraph、Dify、Coze、自研 Runtime权限控制限制 Agent 能操作的范围账号体系、操作白名单、审计日志千问系模型在 Agent 场景中表现出色的原因首先是它提供了不同参数量级的选择。本地开发时可以用小模型跑通流程生产环境再切换到更大模型开发和部署成本可控。其次是 function calling 能力。Agent 的核心是“模型决定调用哪个工具、传入什么参数、如何处理工具返回结果”。Qwen 系列对 function calling 有专门支持模型输出会按照可以被程序解析的结构返回这比让模型自由输出 JSON 再强行解析稳定得多。第三是接口兼容性。通过 Ollama 或 vLLM 启动 Qwen 模型后可以暴露 OpenAI 兼容接口。这意味着你过去写的所有基于 OpenAI 接口的 Agent 代码几乎可以无缝迁移到本地开源模型上只需要改一个 base_url。第四是微调生态。如果通用模型在特定领域的工具调用效果不够好可以用 Qwen 系列的底座模型做指令微调社区里相关的数据集和脚本数量非常多。但要注意一点用开源模型做 Agent不等于所有问题都解决了。模型只是大脑工具执行、记忆管理、任务编排、权限控制这些工程模块仍然需要自己搭建。这些模块的质量往往决定了 Agent 在生产环境能不能真正跑起来。5. 想自己搭一套 Agent 原型环境准备与通用启动方式因为新公司产品还未公开这里给出一套面向通用 Agent 开发的环境准备和启动流程。这套流程的核心目标是跑通“本地模型 OpenAI 兼容接口 function calling”的最小链路。前置环境检查清单如下。操作系统Windows 10/11、Linux 或 macOS 均可。Python 版本建议 3.10 或更高。模型推理工具Ollama、LM Studio 或 vLLM 三者任选其一。硬件建议建议 16GB 内存以上有 NVIDIA 显卡可以明显提升推理速度没有显卡也可以用 CPU 跑小参数模型。磁盘空间根据模型大小预留Qwen 系列从 1.5B 到 32B 不等量化模型通常在 1GB 到 20GB 之间具体以模型文件为准。端口规划Ollama 默认 11434vLLM 默认 8000本地 Web 服务默认 7860如果端口冲突要能手动修改。推荐用 Ollama 启动因为安装最简单并且在本地启动后会自动暴露一个 OpenAI 兼容接口。先安装 Ollama然后拉取一个适合你硬件的 Qwen 模型。# 拉取模型具体标签以你的硬件和 Ollama 支持情况为准 ollama pull qwen3:8b # 启动 Ollama 服务 ollama serve启动成功后可以先用一条命令验证模型是否正常工作。curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen3:8b, messages: [{role: user, content: 你好}]}如果你使用的是 vLLM启动方式类似但需要先确认本地是否已经下载好模型。# 按实际模型路径调整 vllm serve Qwen/Qwen3-8B \ --dtypeauto \ --api-key token-demo-key \ --port 8000这里再次说明以上命令是通用模板。具体模型名称和文件路径需要根据你实际下载的版本替换不能照抄。如果某条命令跑不通优先检查模型是否已经下载、端口是否被占用、Python 和 CUDA 版本是否匹配。模型服务启动之后下一步是把 Agent 的“大脑”接上。下面是一个最小可用的 Python 调用示例演示如何让模型选择调用一个天气工具。import requests url http://127.0.0.1:11434/v1/chat/completions headers { Content-Type: application/json } # 模拟一个天气查询工具 def get_weather(city: str) - str: return f{city} 今日多云气温 22 摄氏度 # Qwen 系列的 function calling 由 tools 参数驱动 payload { model: qwen3:8b, messages: [ {role: user, content: 查一下北京的天气} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } } ], tool_choice: auto } response requests.post(url, jsonpayload, timeout60) print(response.json())这段代码的意义是验证最关键的一环模型能不能根据用户指令生成“调用 get_weather 工具”的决策而不是自己编造一个天气数据。如果返回结果中包含 tool_calls 字段并且里面的函数名是 get_weather、参数是北京就说明 function calling 链路通了。链路通之后真正的 Agent 循环还需要补上工具执行和结果回传。这一步通常在代码中由 Agent Runtime 完成把 tool_calls 解析出来执行本地函数把函数返回值以 tool 消息回传给模型模型再根据结果生成最终回复。6. Agent 功能测试与效果验证Agent 的测试比普通接口测试复杂因为它的输出不是一个固定结构而是多轮决策序列。建议从以下维度建立验证体系。测试项输入示例判断标准任务理解帮我调研 AI Agent 市场输出报告是否能拆解成搜索、阅读、总结、生成报告子任务工具选择查一下北京天气是否调用天气工具而不是直接编造数据参数生成查一下北京天气传给工具的 city 参数是否是“北京”多轮记忆刚才说的城市是哪个是否正确引用前一轮对话信息输出格式以 JSON 格式返回配置是否能稳定输出可被 json.loads 解析的内容异常处理工具调用超时是否有超时、重试或兜底方案实际测试时建议先手工跑 20 条左右的典型任务不要一上来就上自动化。手工测试能看到模型在决策链路中的真实表现比如它有没有理解工具描述、有没有生成错误参数、有没有在结果返回后继续推进任务。手工测试通过后再把这些用例固化成自动化回归集。每次更换模型版本、修改提示词模板、调整工具参数时都重新跑一遍。Agent 系统最怕的不是“第一次不行”而是“改了某个参数之后之前能用的功能突然坏了”。判断一套 Agent 系统能不能进入试用阶段可以设定这样的标准任务拆解符合业务预期没有把简单问题复杂化。工具调用正确率稳定参数错误可以被自动拦截并重试。多轮任务不丢上下文不会在第二轮忘记用户最初的目标。出现异常时能给出明确失败原因而不是假装成功。权限之外的动作被拦截日志完整可回溯。这五条全部达标再考虑接入真实业务数据和用户流量。任何一条不达标都说明 Agent 还处于原型阶段贸然上线会引发不可控问题。7. 接口 API 与批量任务设计Agent 做出来之后最终要对外提供服务。很多 Agent 产品不只是给一个聊天窗口而是要把 Agent 能力嵌入到业务系统里。这个时候接口 API 和批量任务设计就成了重点。对外接口建议先以 OpenAI 兼容协议为基础再增加业务字段。下面是一个通用的 Agent 任务提交接口示例。curl -X POST http://127.0.0.1:8000/agent/run \ -H Content-Type: application/json \ -d { task: 生成一份本周周报, batch_id: B20250101, task_id: T001, caller: dev_zhang, callback_url: http://127.0.0.1:9000/callback }这个示例展示的是一个典型的异步任务提交模式。Agent 任务通常耗时长不适合用同步请求等待结果。正确做法是任务提交成功立即返回一个 task_idAgent 在后台执行执行完成后通过回调方式通知调用方。批量任务设计建议遵循以下原则。设计点建议任务持久化先写入任务队列再开始执行避免程序重启丢任务幂等键用 batch_id 加 task_id 组合防止任务被重复执行超时控制单任务超时和整批超时分开设置限流对同一来源的任务做速率限制防止打爆模型服务日志每次模型调用都记录 model、prompt、tool_calls、output、耗时权限接口只在内网开放或者加 API Key 校验生产环境里的 Agent 批量任务真正的难点不是模型不够强而是任务执行到一半失败了之后如何恢复。建议从第一版就加入失败重试和死信队列。一个任务重试 3 次仍然失败就把它丢进一个专门存放失败任务的目录定时分析失败原因。不要让它永远阻塞在队列里否则一个坏任务会拖垮整批任务。8. 本地部署资源占用与性能观察本地跑 Agent 模型资源占用是需要重点观察的。这里不写死某个模型的固定显存占用因为结论必须从你本机的实际测试中来但可以给出观察方法和经验判断方向。显卡显存观察用 nvidia-smi。nvidia-smi在模型推理过程中观察 GPU 显存占用和利用率。如果你使用的是 Ollama还可以通过 ollama ps 查看当前加载了哪些模型、分别占用多少显存。ollama ps影响资源占用的主要因素是模型参数量、量化级别、上下文长度和并发请求数。同样的模型4bit 量化版本和 8bit 全精度版本显存占用差距往往会达到一倍甚至更多。上下文长度也会显著影响内存和显存占用因为 Agent 任务会积累多轮工具调用结果上下文很容易越拉越长。如果显存不足最有效的几个降载手段是第一换量化版本。优先选 GGUF 的 Q4_K_M 或 Q5_K_M 这类常用量化级别既能明显降低显存占用又能在多数场景保持可用效果。第二换更小的模型。Qwen 系列有多个尺寸把 32B 换到 14B再把 14B 换到 8B显存占用会快速下降。开发阶段完全可以用小模型跑通流程生产环境再评估是否需要升级模型。第三限制上下文长度。这里的核心是给模型调用设置 max_tokens 上限同时在 Agent 循环里做上下文裁剪。早期的工具调用日志不需要全部保留把关键结果摘要化之后存到记忆里可以避免上下文爆炸。第四控制并发。如果模型服务是单卡部署不要同时跑太多 Agent 任务。建议先做一次压力测试看显存达到多少时推理速度明显下降把并发数控制在拐点之内。9. 常见问题与排查方法本地部署 Agent 模型最容易碰到的是下面几类问题。问题现象可能原因排查方式解决方案模型下载慢或失败网络不稳定、镜像源不可用检查网络查看下载日志更换可用的镜像源或使用支持断点续传的下载工具启动后接口无法访问Ollama 或 vLLM 服务没启动查看服务进程和日志重新执行启动命令确认端口未被占用端口被占用其他进程占用了同一端口netstat 或 lsof 查看端口换一个空闲端口同时修改客户端请求地址显存不足模型太大、上下文太长nvidia-smi 观察显存占用换量化版本、换小模型、限制上下文长度接口超时模型推理速度慢、请求量过大查看服务端日志和请求耗时加大超时时间、减小请求量、增加并发控制工具调用乱选或参数错误工具描述不够明确、模型能力不足单独构造工具调用用例测试改写工具描述、调整 system prompt、换更强的模型模型输出是非法 JSON采样参数或提示词导致格式不稳定查看实际输出文本使用受控解码或让模型先输出草稿再自校验关于模型输出非法 JSON 的问题这里多展开一点。很多 Agent 框架要求模型返回结构化的 JSON 内容但开源模型在大模型生成时偶尔会附加多余文字导致 JSON 解析失败。解决办法不是反复重试而是给模型一个固定的输出模板并在返回后做一次格式校验失败时把错误信息回传给模型让它自己修正。10. 最佳实践与使用建议Agent 开发最怕一上来就搭建复杂系统。第一版建议保持最小可用只包含一条任务链路、两个工具、一个模型服务。先把这条链路跑通再逐步增加复杂度。工具调用是 Agent 的核心也是安全风险最集中的地方。任何真实业务操作都应该在工具层做白名单校验。Agent 可以调用“查询订单”工具但不应该在没有二次确认的情况下执行“删除订单”操作。涉及用户数据、支付、发消息、删文件、操作浏览器等敏感功能必须加权限校验和操作日志。从开发到生产建议遵循下面这些工程化原则。第一目录规范化。模型文件、输入素材、输出结果、日志文件分目录管理。不要把所有文件都堆在根目录否则一次批量任务跑下来项目结构会乱到无法维护。第二建立回归测试集。第二次开始不要只做手工验证。把典型的 Agent 任务固化成测试用例每次调整模型或提示词后都要回归一遍。第三保存历史版本。模型版本、提示词版本、工具参数版本都要记录。Agent 系统的表现波动往往不是代码问题而是模型或提示词被悄悄替换了。第四输出复检。Agent 自动生成的内容不能直接发布。尤其面向用户的内容需要增加审核环节或者在生成后做关键词和内容安全检查。第五合规边界。涉及人脸、声音、版权素材、用户隐私数据时必须确认已经获得合法授权。开源模型也要遵守对应的模型许可协议。把 Agent 用于商业场景之前建议先审查一遍数据来源和输出用途。11. 总结与下一步林俊旸创业、新公司剑指 Agent、腾讯跟投这三个信息点放在一起指向一个判断Agent 正在从概念验证进入工程化落地阶段。一个做过千问开源模型的人选择这个方向创业说明 Agent 的想象空间已经足够支撑一个新公司从零起步。对开发者来说现在最有价值的事情不是等待新公司发布产品而是先用千问系开源模型把 Agent 最小链路跑通本地拉起模型服务验证 OpenAI 兼容接口写一个 function calling 工具调用示例再逐步加入记忆、任务编排和批量任务队列。这套流程今天就能动手做。最容易踩的坑有三个一是工具调用格式不稳定模型输出的内容不能被程序直接解析二是上下文越拉越长显存和内存开销暴涨三是权限控制太弱Agent 在测试环境可以随意操作一旦接真实业务就会出无法挽回的问题。这篇文章里的代码都是通用模板适合用来搭建自己的 Agent 验证环境。林俊旸新公司的具体产品形态还不清楚建议收藏这篇文章等官方信息发布后再回来对照验证。到那时候你会发现Agent 的技术栈并没有那么神秘核心还是模型、工具、记忆和编排这四件事。