这两年，大家都在聊 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 可能会告诉你：

git clone xxx
cd project
docker compose 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，就想着：

while True:
    response = llm(...)

然后加一个 Tool Calling。

最后发现 Demo 能跑，但是一放到真实业务里就非常难用。

我做 Agent 时，通常第一件事情不是写 Agent，而是：

先把能力拆出来。

比如我希望 AI 能够完成图片生成。

那我不会直接把“图片生成逻辑”硬编码进 Agent。

我会先做一个独立能力：

generate_image

如果需要图片编辑，再增加：

edit_image

如果是视频：

generate_video
get_video_status

如果是服务器：

execute_shell
read_file
write_file
restart_service

如果是 GitHub：

search_repository
read_file
create_issue
create_pull_request

Agent 最终只是：

这些能力的调度器。

这也是我现在越来越认同的一种 Agent 架构。

---

三、我的 Agent 架构：Model + Tools + Context + Loop

如果把我现在理解的 Agent 极度简化，可以写成：

Agent = LLM + Tools + Context + Loop

分别解释一下。

1. LLM

也就是 Agent 的“大脑”。

比如：

GPT
Claude
Gemini
DeepSeek
Grok

模型主要负责：

理解目标
分析问题
制定下一步行动
选择工具
解析工具结果
判断任务是否完成

但是模型本身通常不负责真正执行任务。

---

2. Tools

Tool 是 Agent 的“手”。

比如：

搜索网页
执行 Shell
查询数据库
调用 API
读写文件
发送邮件
生成图片
生成视频
操作浏览器
读取 GitHub

如果没有 Tool，模型再聪明，也只能聊天。

所以我现在越来越重视 Tool 层。

甚至我认为：

未来很多 Agent 产品真正的护城河，不一定是模型，而是工具生态。

---

3. Context

Context 是 Agent 的“工作记忆”。

里面可能包括：

用户需求
历史对话
项目文件
代码仓库
数据库信息
工具执行结果
环境变量
系统规则
业务规则

比如用户说：

把刚才那个项目部署一下。

这里的“刚才那个项目”是什么？

Agent 必须知道。

所以 Context Management 是做复杂 Agent 时绕不开的问题。

---

4. Loop

最后一个才是 Agent 最重要的部分：

Loop

Agent 并不是调用一次模型就结束。

而是：

思考
↓
行动
↓
观察
↓
再思考
↓
再行动

一直执行，直到：

Task Completed

抽象一点就是：

while not task_completed:

    decision = llm(context)

    if decision.type == "tool":
        result = execute_tool(decision.tool)
        context.append(result)

    elif decision.type == "answer":
        return decision.answer

很多 Agent 框架，本质上都是在这个循环上不断增加能力。

---

四、先从最简单的 Agent 开始

我们可以直接用 Python 写一个非常简单的 Agent。

假设使用 OpenAI 兼容协议。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.example.com/v1"
)

messages = [
    {
        "role": "system",
        "content": """
你是一个 AI Agent。

你的目标不是单纯回答问题，
而是分析任务，并决定应该采取什么行动。
"""
    },
    {
        "role": "user",
        "content": "帮我计算 123 * 456"
    }
]

response = client.chat.completions.create(
    model="gpt-5",
    messages=messages
)

print(response.choices[0].message.content)

这个还不是 Agent。

因为它没有行动能力。

接下来，我们给它加工具。

---

五、给 Agent 加第一只“手”

例如增加一个计算工具：

def calculator(a, b, operator):

    if operator == "+":
        return a + b

    if operator == "-":
        return a - b

    if operator == "*":
        return a * b

    if operator == "/":
        return a / b

    raise ValueError("unsupported operator")

定义 Tool Schema：

tools = [
    {
        "type": "function",
        "function": {
            "name": "calculator",
            "description": "执行数学计算",
            "parameters": {
                "type": "object",
                "properties": {
                    "a": {
                        "type": "number"
                    },
                    "b": {
                        "type": "number"
                    },
                    "operator": {
                        "type": "string",
                        "enum": ["+", "-", "*", "/"]
                    }
                },
                "required": [
                    "a",
                    "b",
                    "operator"
                ]
            }
        }
    }
]

然后交给模型：

response = client.chat.completions.create(
    model="gpt-5",
    messages=messages,
    tools=tools
)

模型可能不会直接回答：

56088

而是返回：

{
  "name": "calculator",
  "arguments": {
    "a": 123,
    "b": 456,
    "operator": "*"
  }
}

Agent 程序再真正执行：

result = calculator(
    a=123,
    b=456,
    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_name = call["name"]

tool = TOOLS.get(tool_name)

if not tool:
    raise RuntimeError(
        f"unknown tool: {tool_name}"
    )

result = tool(**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.md

SKILL.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
↓
Service

Tool 告诉 AI：

“我能做什么。”

Skill 告诉 AI：

“这件事应该怎么做好。”

这是两种完全不同的东西。

例如一个 curl Tool 理论上可以调用全世界几乎所有 HTTP API。

但你不能因此说：

curl = GitHub Skill

GitHub 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
...

如果每接一个模型，都单独写一套 SDK：

OpenAIClient
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 架构最好是：

agent = Agent(
    model=ModelProvider(
        name="gpt-5.6-sol"
    )
)

然后可以直接：

agent.model = ModelProvider(
    name="deepseek"
)

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         Skills

Agent 不需要把所有东西永远放在 Prompt 里面。

需要的时候再取。

---

十四、Memory 和数据库不是一回事

这也是非常容易混淆的一个概念。

Memory 并不是单纯：

INSERT INTO memories ...

Agent 的 Memory 至少可以分：

Working Memory
Short-term Memory
Long-term Memory
User Memory
Task Memory

例如：

Working Memory

当前任务：

正在修复 Nginx 403。

Short-term Memory

刚才发现：

文件路径：
/data/static/newlogo.png

Long-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-Agent

Multi-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 有价值的地方。

---

十九、我为什么越来越关注 MCP

MCP 对 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
打开 Excel

AI 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-loop

Agent 最怕的其实不是功能少。

而是：

什么都能做，
但是没有一件事能稳定做完。

---

二十五、最后

我从传统后端开发一路做到现在，越来越明显地感觉到一个变化：

过去我们写程序，是我们自己把流程写死。

if condition {
    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 真正拥有干活的能力。

一起成为勇猛精进的人类。