王仕宇是如何做 AI Agent 的：从模型调用，到真正能干活的智能体

这两年大家都在聊 AI Agent。有人觉得 Agent 就是给 ChatGPT 加几个工具有人觉得 Agent 就是工作流还有人认为只要接上 MCP就算做出了 Agent。但我自己真正做下来以后越来越觉得AI Agent 的核心不是“让 AI 会聊天”而是让 AI 能够在真实环境里完成任务。我是王仕宇一个写了很多年代码的程序员。过去几年我做过 Java、Go、Python、Node.js也做过网站、微信小程序、macOS 应用、API 平台和各种开发者工具。最近一段时间我把越来越多精力放到了 AI Agent 上。而且我做 Agent 的思路可能和很多纯 AI 从业者不太一样。我并不是先研究“怎么让模型更聪明”而是从工程师的角度出发怎么让模型接入现有系统怎么调用真实工具怎么操作文件怎么执行代码怎么访问数据库怎么调用图片、视频模型怎么让它把一个任务真正做完这篇文章我想完整讲一下我是如何理解和实践 AI Agent 的。一、我理解的 AI Agent到底是什么先说一个最简单的定义。普通大模型的工作流程通常是用户输入 ↓ 大模型 ↓ 返回文字比如用户 帮我写一个 Nginx 配置。 AI server { listen 80; ... }到这里AI 的任务就结束了。它只能告诉你“应该怎么做”。但是 Agent 不一样。一个真正的 Agent更像这样用户提出目标 ↓ Agent 理解任务 ↓ 分析当前环境 ↓ 决定下一步行动 ↓ 调用工具 ↓ 获取执行结果 ↓ 再次判断 ↓ 继续调用工具 ↓ 直到任务完成例如用户 帮我把这个 Go 项目部署到服务器。传统 AI 可能会告诉你gitclone xxxcdprojectdockercompose up-d但是 Agent 应该能够真正去执行1. SSH 登录服务器 2. 查看系统版本 3. 判断 Docker 是否安装 4. 安装 Docker 5. clone 项目 6. 检查 docker-compose.yml 7. 修改配置 8. 启动容器 9. 查看日志 10. 请求健康检查接口 11. 如果失败继续排查 12. 部署成功后返回结果这就是我认为 Agent 和普通 ChatBot 最大的区别。一句话概括ChatBot 给你答案Agent 帮你做事。二、我做 Agent第一步不是写 Agent这一点其实非常重要。很多人一开始做 Agent就想着whileTrue:responsellm(...)然后加一个 Tool Calling。最后发现 Demo 能跑但是一放到真实业务里就非常难用。我做 Agent 时通常第一件事情不是写 Agent而是先把能力拆出来。比如我希望 AI 能够完成图片生成。那我不会直接把“图片生成逻辑”硬编码进 Agent。我会先做一个独立能力generate_image如果需要图片编辑再增加edit_image如果是视频generate_video get_video_status如果是服务器execute_shell read_file write_file restart_service如果是 GitHubsearch_repository read_file create_issue create_pull_requestAgent 最终只是这些能力的调度器。这也是我现在越来越认同的一种 Agent 架构。三、我的 Agent 架构Model Tools Context Loop如果把我现在理解的 Agent 极度简化可以写成Agent LLM Tools Context Loop分别解释一下。1. LLM也就是 Agent 的“大脑”。比如GPT Claude Gemini DeepSeek Grok模型主要负责理解目标 分析问题 制定下一步行动 选择工具 解析工具结果 判断任务是否完成但是模型本身通常不负责真正执行任务。2. ToolsTool 是 Agent 的“手”。比如搜索网页 执行 Shell 查询数据库 调用 API 读写文件 发送邮件 生成图片 生成视频 操作浏览器 读取 GitHub如果没有 Tool模型再聪明也只能聊天。所以我现在越来越重视 Tool 层。甚至我认为未来很多 Agent 产品真正的护城河不一定是模型而是工具生态。3. ContextContext 是 Agent 的“工作记忆”。里面可能包括用户需求 历史对话 项目文件 代码仓库 数据库信息 工具执行结果 环境变量 系统规则 业务规则比如用户说把刚才那个项目部署一下。这里的“刚才那个项目”是什么Agent 必须知道。所以 Context Management 是做复杂 Agent 时绕不开的问题。4. Loop最后一个才是 Agent 最重要的部分LoopAgent 并不是调用一次模型就结束。而是思考 ↓ 行动 ↓ 观察 ↓ 再思考 ↓ 再行动一直执行直到Task Completed抽象一点就是whilenottask_completed:decisionllm(context)ifdecision.typetool:resultexecute_tool(decision.tool)context.append(result)elifdecision.typeanswer:returndecision.answer很多 Agent 框架本质上都是在这个循环上不断增加能力。四、先从最简单的 Agent 开始我们可以直接用 Python 写一个非常简单的 Agent。假设使用 OpenAI 兼容协议。fromopenaiimportOpenAI clientOpenAI(api_keyYOUR_API_KEY,base_urlhttps://api.example.com/v1)messages[{role:system,content: 你是一个 AI Agent。 你的目标不是单纯回答问题 而是分析任务并决定应该采取什么行动。 },{role:user,content:帮我计算 123 * 456}]responseclient.chat.completions.create(modelgpt-5,messagesmessages)print(response.choices[0].message.content)这个还不是 Agent。因为它没有行动能力。接下来我们给它加工具。五、给 Agent 加第一只“手”例如增加一个计算工具defcalculator(a,b,operator):ifoperator:returnabifoperator-:returna-bifoperator*:returna*bifoperator/:returna/braiseValueError(unsupported operator)定义 Tool Schematools[{type:function,function:{name:calculator,description:执行数学计算,parameters:{type:object,properties:{a:{type:number},b:{type:number},operator:{type:string,enum:[,-,*,/]}},required:[a,b,operator]}}}]然后交给模型responseclient.chat.completions.create(modelgpt-5,messagesmessages,toolstools)模型可能不会直接回答56088而是返回{name:calculator,arguments:{a:123,b:456,operator:*}}Agent 程序再真正执行resultcalculator(a123,b456,operator*)得到56088然后把结果重新交给模型。这时候AI 就第一次从“回答问题”进化到了“调用能力解决问题”六、我更喜欢把 Tool 做成独立模块随着工具越来越多如果全部写在一个 Agent 文件里很快就会变成这样agent.py ├── calculator ├── search ├── shell ├── image ├── video ├── github ├── email ├── database └── ...最后代码越来越不可维护。所以我更喜欢agent/ ├── main.py ├── tools/ │ ├── shell.py │ ├── browser.py │ ├── image.py │ ├── video.py │ ├── github.py │ └── database.py ├── prompts/ │ └── system.md ├── memory/ │ └── manager.py └── llm/ └── client.py然后统一注册TOOLS{shell:shell_tool,browser:browser_tool,generate_image:generate_image,generate_video:generate_video,github:github_tool}执行的时候tool_namecall[name]toolTOOLS.get(tool_name)ifnottool:raiseRuntimeError(funknown tool:{tool_name})resulttool(**call[arguments])这样 Agent 本身就变得非常干净。七、我为什么开始重视 Skill做到这里会出现第二个问题。Tool 太底层。比如curl read_file write_file shell browser这些是能力但是还不是“经验”。举个例子。如果我告诉 AI给我生成一张 16:9 的文章封面。底层 Tool 可能只有generate_image(prompt, width, height)但 AI 还需要知道什么时候调用 参数怎么组织 提示词怎么写 失败后怎么重试 图片生成后保存到哪里 最终怎么返回这时候我就会在 Tool 之上再增加一层Skill我现在更愿意把它理解成Skill Tool Instructions Workflow Best Practice例如image-generation-skill/ ├── SKILL.md ├── scripts/ │ └── generate.py └── examples/ └── prompts.mdSKILL.md可以告诉 Agent# Image Generation Skill 当用户要求 - 生成图片 - 制作封面 - 绘制插图 - 制作海报 使用本 Skill。 ## Workflow 1. 分析用户需要的画面 2. 判断比例 3. 优化 Prompt 4. 调用图片模型 5. 检查返回结果 6. 返回最终图片这就比单纯暴露 API 好很多。八、为什么我认为 Skill 非常重要过去的软件是UI ↓ API ↓ Service ↓ Database但 Agent 时代中间可能会增加一层User ↓ Agent ↓ Skill ↓ Tool ↓ API ↓ ServiceTool 告诉 AI“我能做什么。”Skill 告诉 AI“这件事应该怎么做好。”这是两种完全不同的东西。例如一个curlTool 理论上可以调用全世界几乎所有 HTTP API。但你不能因此说curl GitHub SkillGitHub Skill 应该包含什么时候查询仓库 怎么搜索代码 怎么读取 Issue 怎么判断问题 怎么修改代码 怎么创建 PR所以我觉得以后 AI Agent 的竞争很可能会逐渐从谁接的模型多变成谁拥有更多高质量 Skill九、我正在做的一个方向让 Agent 获得 AI 生成能力这是我目前特别感兴趣的一件事情。大模型本身很强但很多 Agent 默认只能写代码 搜索 运行命令 读写文件但如果给它增加图片生成 图片编辑 视频生成 视频编辑 语音 OCR能力就完全不同了。例如一个文章 Agent用户 帮我写一篇 DeepSeek V4 的文章 并且配三张图。Agent 可以自己1. 搜集资料 2. 整理文章结构 3. 写正文 4. 判断哪里需要图片 5. 为图片生成 Prompt 6. 调用图片模型 7. 保存图片 8. 插入 Markdown 9. 输出完整文章而不是像以前一样AI 写文章 ↓ 人再打开 Midjourney ↓ 自己写 Prompt ↓ 下载图片 ↓ 重新插入文章Agent 可以把整个流程闭环。十、再进一步视频 Agent图片只是开始。比如我说制作一个 30 秒的 AI 产品宣传视频。Agent 可以拆成目标 ↓ 生成脚本 ↓ 拆分镜头 ↓ 生成分镜 Prompt ↓ 生成图片 ↓ 生成视频 ↓ 生成旁白 ↓ 生成字幕 ↓ 合成 ↓ 输出最终视频甚至可以自动拆成Scene 01 Scene 02 Scene 03 Scene 04 Scene 05每一个 Scene 都执行Generate Image ↓ Image to Video ↓ Check Result最后FFmpeg ↓ 合成 ↓ 字幕 ↓ 音乐 ↓ Final.mp4这时候 Agent 就不再是一个聊天窗口了。它变成了一套自动化生产系统。十一、我做 Agent 非常看重 API 标准化这也是我做 API 中转、模型兼容这一类东西以后一个非常明显的感受。现在 AI 模型很多OpenAI Claude Gemini DeepSeek Grok Kling 即梦 MiniMax ...如果每接一个模型都单独写一套 SDKOpenAIClient ClaudeClient DeepSeekClient GrokClient ...Agent 会越来越复杂。所以我比较喜欢做一层统一协议。例如统一成/v1/chat/completions或者/v1/responses然后模型只是{model:gpt-5.6-sol}换成{model:deepseek-v4}或者{model:grok}对于 Agent 来说底层模型就可以快速切换。架构变成Agent │ ▼ Unified AI Gateway │ ├── OpenAI ├── Claude ├── DeepSeek ├── Grok ├── Gemini ├── Image └── Video这也是我越来越重视 AI Gateway 的原因。十二、Agent 不应该绑定某一个模型我自己现在有一个很明确的观点Agent 和 Model 应该解耦。Agent 是任务系统Model 是推理引擎两者不是一回事。今天可能Claude更适合写代码。明天可能GPT更适合复杂工具调用。另外一个模型可能DeepSeek成本更低。所以一个好的 Agent 架构最好是agentAgent(modelModelProvider(namegpt-5.6-sol))然后可以直接agent.modelModelProvider(namedeepseek)Agent 的Tools Memory Skills Workflow Permissions都不需要改变。十三、真正复杂的是 Context不是 API最开始做 Agent 时很容易觉得最难的是Tool Calling但实际上做到后面会发现Tool Calling 很简单。真正复杂的是 Context。比如一个 Agent 连续干了 100 步。每一步都产生Prompt Tool Call Tool Result 日志 文件内容 错误信息如果全部塞进上下文Token 爆炸所以必须考虑Context Compression Memory Summary Retrieval Workspace例如短期信息 → Context 长期信息 → Memory 大量文件 → Workspace 历史知识 → Retrieval我比较喜欢这种思路┌──────────────┐ │ Memory │ └──────┬───────┘ │ User → Agent → Context Manager │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Files Tools SkillsAgent 不需要把所有东西永远放在 Prompt 里面。需要的时候再取。十四、Memory 和数据库不是一回事这也是非常容易混淆的一个概念。Memory 并不是单纯INSERTINTOmemories...Agent 的 Memory 至少可以分Working Memory Short-term Memory Long-term Memory User Memory Task Memory例如Working Memory当前任务正在修复 Nginx 403。Short-term Memory刚才发现文件路径 /data/static/newlogo.pngLong-term Memory这个服务器使用 CentOS Nginx 配置位于 /etc/nginx/conf.d/User Memory用户通常使用 Go 使用 Docker 服务器主要用 Nginx有了这些以后同一个 Agent 才会越来越懂用户。十五、Agent 一定需要权限系统这是我认为很多 Demo 完全没有考虑的问题。如果 Agent 能执行rm-rf/那显然很危险。所以真实 Agent 必须给 Tool 分权限。例如Level 0 只读 Level 1 低风险写操作 Level 2 系统操作 Level 3 危险操作比如TOOLS{read_file:{permission:0},write_file:{permission:1},restart_nginx:{permission:2},delete_database:{permission:3}}危险操作需要Human Approval例如Agent 准备执行 DROP TABLE users; 该操作可能导致数据永久删除。 是否继续所以我不太认可一种观点Agent 越自主越好。我更认为Agent 应该在明确的权限边界内尽可能自主。十六、我做 Agent 很看重“可观察性”普通脚本失败看日志。Agent 失败会复杂很多。因为你需要知道模型为什么选择这个工具 调用参数是什么 工具返回了什么 为什么又调用另一个工具 Token 用了多少 任务用了多少钱 执行了多少步所以最好记录完整 Trace。例如{task_id:task_001,step:7,model:gpt-5.6-sol,action:tool_call,tool:execute_shell,arguments:{command:docker ps},duration:812,status:success}一个完整 Agent 系统我认为至少应该能够看到Task ↓ Step ↓ LLM Request ↓ Tool Call ↓ Tool Result ↓ Cost ↓ Latency否则出问题以后很难调试。十七、我不太喜欢一开始就上 Multi-AgentMulti-Agent 最近特别火。架构看起来很漂亮Manager Agent │ ├── Research Agent ├── Coding Agent ├── Test Agent ├── Review Agent └── DevOps Agent但是如果一个 Agent 都没做好直接上五个 Agent往往只是五倍 Token 五倍 Debug 难度我更推荐单 Agent 多个 Skill 多个 Tool真正遇到上下文隔离 角色专业化 并行任务 独立权限再拆成 Multi-Agent。十八、我理想中的 Coding Agent因为我是程序员所以 Coding Agent 是我非常关注的一类 Agent。我觉得一个真正能用的 Coding Agent不应该只是帮我补全代码。而应该至少拥有Repository Search File Read File Write Shell Git Test Build Lint Browser Documentation Search用户说修复这个接口 500。Agent 应该自己完成搜索接口 ↓ 找到 Controller ↓ 找到 Service ↓ 找到数据库调用 ↓ 复现错误 ↓ 查看日志 ↓ 修改代码 ↓ 运行测试 ↓ 启动项目 ↓ 请求接口 ↓ 确认修复这才是真正让我觉得 Agent 有价值的地方。十九、我为什么越来越关注 MCPMCP 对 Agent 最大的意义在我看来不是“又一个协议”。而是它在尝试标准化 Agent 和外部世界连接的方式。以前每一个 Agent 都自己写GitHub Adapter Database Adapter Browser Adapter Slack Adapter Filesystem Adapter以后理论上可以变成Agent ↓ MCP ↓ Tools比如Claude Code Codex Cursor OpenCode如果都能够消费类似的 MCP Server那么一个能力就不用重复开发很多遍。这件事情对开发者特别重要。二十、但是我认为 Skill 可能比 MCP 更值得关注MCP 解决的是怎么连接工具。Skill 解决的是怎么使用工具完成任务。例如MCP 我可以操作 GitHub。而 Skill当用户要求修复 Bug 时 1. 搜索相关 Issue 2. 定位代码 3. 创建分支 4. 修改代码 5. 执行测试 6. 检查 Diff 7. 创建 Pull Request因此我现在比较喜欢这样的架构Agent │ ┌───────┴────────┐ │ │ Skills Memory │ ▼ MCP │ ▼ Tools │ ▼ External Systems二十一、我现在怎么看 Agent 的商业机会如果只做ChatGPT 套壳我觉得空间会越来越小。因为基础模型厂商自己就能做。真正有价值的地方可能在下面几层。第一层模型OpenAI Anthropic Google DeepSeek xAI普通开发者很难参与训练基础模型。第二层AI Gateway解决统一 API 模型路由 计费 限流 Fallback 多 Key 负载均衡第三层Tools / MCP解决Agent 能做什么。第四层Skills解决Agent 怎么把事情做好。第五层Vertical Agent例如编程 Agent 电商 Agent 内容 Agent 运维 Agent 销售 Agent 客服 Agent 视频 Agent我个人更看好后面三层。二十二、我自己真正想做的不是一个“万能聊天机器人”如果让我总结一下我现在做 AI Agent 的方向我不会说我要做一个更聪明的 ChatGPT。我更希望做的是给 AI 不断增加能力。今天增加图片生成明天增加视频生成后天增加服务器运维然后再增加GitHub Browser Database Email Search Payment Deployment最后一个模型背后可能拥有几十个甚至几百个 Skill。用户只需要告诉它我想做什么。剩下的问题由 Agent 自己拆解。这才是我眼里的 Agent。二十三、最终形态可能是一个 AI 操作系统再往后想一步。现在电脑的模式是人 ↓ GUI ↓ Application ↓ Operating System用户需要自己打开浏览器 打开 VS Code 打开终端 打开 Photoshop 打开 ExcelAI Agent 时代可能变成人 ↓ 自然语言 ↓ Agent ↓ Skill / Tool ↓ Application / API / OS用户不再需要知道哪个软件能完成这件事。只需要说帮我把昨天的数据整理成 Excel 分析异常 生成一份报告 再发给团队。Agent 自己决定查数据库 ↓ Python ↓ Excel ↓ Chart ↓ PDF ↓ Email所以从这个角度看Agent 本质上可能是在重新定义人与计算机之间的交互层。二十四、如果今天让我重新从 0 开始做 Agent我的路线会非常简单。先不要做什么超级 Agent 通用 Agent AutoGPT 2.0 Multi-Agent Platform先做一个很具体的问题。比如代码 Agent第一阶段只给它read_file write_file search shell做到可以修一个真实 Bug。第二阶段加入Git Test Browser做到可以完成一个完整 Issue。第三阶段加入Memory Skill MCP第四阶段再考虑Multi-Agent Planning Long-running Task Human-in-the-loopAgent 最怕的其实不是功能少。而是什么都能做 但是没有一件事能稳定做完。二十五、最后我从传统后端开发一路做到现在越来越明显地感觉到一个变化过去我们写程序是我们自己把流程写死。ifcondition{doA()}else{doB()}未来越来越多的软件会变成目标 规则 工具 环境然后由模型动态决定下一步做什么。这是一个非常大的变化。以前我们写的是Workflow未来越来越多时候我们写的可能是Capability我们不再需要告诉系统第一步必须做什么 第二步必须做什么 第三步必须做什么。而是告诉 Agent你有什么工具 你有什么权限 你必须遵守什么规则 最终目标是什么。剩下的路径让它自己寻找。所以如果你问我王仕宇是如何做 AI Agent 的我的答案并不是用了哪个框架也不是用了哪个模型。而是四句话把能力做成 Tool。把经验做成 Skill。把模型当成大脑。让 Agent 在真实环境中把任务跑完。模型会越来越强。GPT、Claude、Gemini、DeepSeek、Grok 还会不断迭代。但我觉得对于普通开发者来说真正值得积累的东西是Tools Skills Workflow Context Memory Infrastructure Domain Knowledge因为模型可以替换。而这些东西最终会组成属于你自己的 Agent 能力体系。这也是我现在研究 AI Agent 最感兴趣的地方。不是再做一个聊天机器人。而是让 AI 真正拥有干活的能力。一起成为勇猛精进的人类。