想做个 AI Agent,到底该从哪下手?

AI 工程拆解

拨开那一堆框架名词，开发一个 Agent，本质上只有三件事。

1. 先想明白一件事：Agent 到底是什么

每次有人问"想做个 Agent 该从哪下手"，我都建议先别急着选框架。因为市面上所有 agent 框架，骨架都是同一个：

Agent = 模型 + 工具 + 循环。

一句话展开：你给模型一组工具的定义，模型自己决定调用哪个；你的宿主代码负责执行工具、把结果喂回去；模型拿到结果，接着决定下一步——这样循环下去，直到任务完成。

用户输入 → 模型推理 → 要调工具吗？
              │ 是                  │ 否
              ▼                     ▼
        执行工具 → 结果喂回模型     输出最终回答，结束
              └────────循环────────┘

就这么个循环。LangGraph、CrewAI、Coze、Claude Agent SDK，全都是在这个循环外面包东西：包权限、包沙箱、包记忆、包可视化界面、包多 agent 编排。内核没变过。

把这一点想透，下面所有的选择题——选哪条路线、用什么技术、怎么让用户用上——就都有了判断的锚。

2. 三条开发路线：区别只在"谁来跑这个循环"

既然 Agent 的内核是个循环，那第一个真正的决策就是：这个循环，谁来跑？

按托管程度从轻到重，有三条路线：

2.1 自己跑：API + tool use（最灵活）

核心就是几十行循环。如果不想手写，官方 SDK 的 tool runner 会直接帮你把循环兜起来：

import anthropic
from anthropic import beta_tool

client = anthropic.Anthropic()

@beta_tool
def get_weather(location: str) -> str:
    """查询某地天气。

    Args:
        location: 城市名，如"北京"
    """
    return f"{location}：晴，25°C"

runner = client.beta.messages.tool_runner(
    model="claude-opus-4-8",
    max_tokens=16000,
    tools=[get_weather],
    messages=[{"role": "user", "content": "上海天气怎么样？"}],
)
for message in runner:        # 自动循环：调工具 → 喂结果 → 直到完成
    print(message)

需要更细的控制——人工审批、条件执行、自定义日志——就把循环手写出来：调 messages.create() → 检查 stop_reason <mark style="background: transparent; color: #d4520e; font-weight: 700; padding: 0 2px;"> "tool_use" → 执行工具 → 把 tool_result 追加回 messages → 再调一次，直到 end_turn。手写循环没有任何魔法，它就是上面那张流程图的代码版。

2.2 复用骨架：Claude Agent SDK

如果你要做的是"操作文件和命令行"那一类 agent（编码助手、运维 agent），从零搭工具集、权限、上下文管理很不划算。Claude Agent SDK 把 Claude Code 的整套 harness——工具集、权限系统、上下文压缩、hooks、MCP 接入、subagent——做成了库。你写少量代码，就得到一个能干活的通用 agent。

2.3 全托管：Managed Agents（beta）

连服务器都不想管，就上托管 Agent。它的模型长这样：

Agent（配置，建一次）→ Session（每次运行）→ 事件流（收发消息 / 工具调用）

• 你创建一个持久化的 Agent 配置（模型、system prompt、工具），建一次反复引用，带版本管理；
• 每次运行开一个 Session，Anthropic 给每个 session 分配独立容器，bash 和文件操作都在云端沙箱里跑；
• 通过 SSE 事件流收发消息，自定义工具的执行回调到你自己的程序；
• 自带定时调度（cron）、Webhook 通知、跨会话记忆、文件 / GitHub 仓库挂载、Skills。

2.4 MCP：它不是第四条路线

很多人把 MCP 也丢进"做 Agent"的选项里，这是个误会。MCP（Model Context Protocol）不是 agent，而是给 agent 供给工具和数据的标准协议。

你写一个 MCP server，把数据库、内部 API、业务能力暴露出来；任何支持 MCP 的宿主——Claude Code、Claude.ai、各种第三方客户端——都能直接接上。

所以这里有个很实用的判断：如果你的目标是"让别人的 agent 用上我的能力"，那么开发一个 MCP server，比开发一个完整 agent 划算得多。

3. 需要的技术栈：从"能跑"到"生产级"

把循环跑起来，需要的东西其实不多；但要做成线上能用的产品，要补的功课就不少。分两档看。

3.1 必须的（不然跑不起来）

这里有个新手最容易踩的坑：工具的描述写得好不好，直接决定模型调不调得对。别只写"这个工具查天气"，要写清楚"什么情况下用它、参数是什么、返回什么"——模型就是靠这段描述来做决策的。

3.2 做到生产级还得补的

最后这条最容易被忽略：没有 evals，你改 prompt 就是在盲改。今天调好了 A 场景，明天可能就把 B 场景改坏了，而你根本不知道。

4. 用户从哪进来：Agent 的 7 种入口

agent 写好了，怎么"长"到用户面前？这一步常被忽略，但它决定了产品形态。常见有 7 种：

1. 聊天 Web UI
   ——最常见。自建前端 + 后端流式转发，或嵌进现有产品当侧边栏 Copilot。
2. CLI
   ——终端交互，开发者向（Claude Code 就是这个形态）。
3. IM 机器人
   ——Slack / 飞书 / 钉钉 / 微信 / Telegram bot，用户在已有聊天工具里 @它；消息排队机制天然适配 agent"单轮跑很久"的特性。
4. IDE 插件
   ——VS Code / JetBrains 扩展，贴着代码工作。
5. 无界面后台
   ——根本没有"聊天"入口。定时触发：每晚跑日报、每周扫合规（托管 Agent 的 cron 直接支持）；事件触发：GitHub push、新工单、表单提交 → webhook 拉起一次运行，结果发邮件或写回系统。
6. MCP server 形式
   ——你不做任何 UI，用户在 Claude.ai 或 Claude Code 里连上你的 server，入口是别人的宿主。
7. 嵌入式 API
   ——agent 作为你产品的一个后端能力（"一键生成报告"按钮背后就是个 agent），用户甚至不知道有 agent 存在。

选哪种，取决于你的用户已经在哪。别让用户为了用你的 agent 专门换一个工具——他们在飞书里办公，你就做飞书 bot；他们在 VS Code 里写代码，你就做 IDE 插件。

5. 慢着——你真的需要一个 Agent 吗？

这一节本该放前面，但放这里你更有体感了。不是所有任务都值得做成 agent。 动手之前，拿这四个标准过一遍，任何一条不满足，就退回更简单的方案（单次模型调用，或固定流程的 workflow）：

• ☐ 复杂度：任务是不是多步、且难以事先完全规定？（"把设计文档变成 PR"才需要 agent；"提取 PDF 标题"一次调用就够了）
• ☐ 价值：结果值不值得更高的成本和延迟？agent 跑一轮又慢又贵。
• ☐ 可行性：模型擅不擅长这类任务？
• ☐ 错误成本：出错了能不能被发现、被恢复？（有没有测试、人工审核、回滚）

记住：能用 workflow 解决的，就别上 agent。固定流程用固定流程，把"自主决策"留给真正需要它的地方。

6. 框架格局速览（2026 年中）

前面说的 Claude Agent SDK / Managed Agents 只是 Anthropic 一家。把视野放大，市面上分四层。

6.1 模型厂商官方

6.2 第三方开源框架（写代码）

6.3 低代码 / 可视化平台（少写或不写代码）

6.4 协议层（不是框架，是互通标准）

• MCP
  （Anthropic 发起）：agent ↔ 工具 / 数据的标准接口，已是事实标准，OpenAI、Google、Coze、Dify 均已接入。
• A2A
  （Google 发起，已捐给 Linux 基金会）：agent ↔ agent 之间的互通协议。

这一堆怎么快速区分？盯住四个维度就够了：

① 代码框架   vs  低代码平台      →  工程团队          vs  业务 / 运营
② 绑自家模型 vs  模型无关        →  OpenAI/Claude SDK vs  LangGraph/Dify
③ 自己托管   vs  厂商托管运行时  →  自建循环          vs  Managed Agents
④ 单 agent   vs  多 agent 编排   →  简单任务          vs  图编排 / 角色分工

一句话给个现状：海外生产环境 LangGraph 第一梯队，国内 Coze 和 Dify 当道，而 MCP 基本是个必选项——选任何框架，都先确认它支持 MCP。

7. 给新手的起步路径（照着走就行）

说了这么多，落到行动上，我的建议是别一上来就纠结选型。按这个顺序走：

第一步，用 Python + Anthropic SDK 的 tool runner，写一个带 2-3 个工具的最小 agent。 半天能跑通。目的不是做产品，是亲手感受那个循环==——跑通的那一刻，你会一下子明白前面讲的所有概念。

第二步，入口先用 CLI 或一个极简网页验证价值。 别花一周做漂亮 UI，先确认这个 agent 真有人用、真能解决问题。

第三步，跑顺了，再按需要升级：

• 想省运维 → 迁到 Managed Agents；
• 能力要被别人复用 → 拆成 MCP server；
• 要做通用工作台型 agent → 上 Claude Agent SDK。

顺序很重要：先理解循环，再验证价值，最后才谈选型和规模化。倒过来做——先纠结框架、先堆架构——是新手最常见、也最浪费时间的弯路。

回到开头那个问题：想做个 Agent 该从哪下手？答案不是"先选个框架"，而是——今天下午就写一个几十行的循环，让它真的调用一次工具。剩下的判断，你跑通之后自然会有。

参考资料

[1] Anthropic, 《Building Effective Agents》, anthropic.com/engineering, 2024 [2] Anthropic, Claude Agent SDK 与 Agent 文档, docs.anthropic.com [3] Model Context Protocol 官方文档, modelcontextprotocol.io [4] 本文路线与框架格局部分整理自《Agent 开发指南》（内部资料）, 2026-06-11

关注「人工智能AI技术圈」

获取更多 AI 与机器人前沿动态

大模型 · 智能体 · 机器人 · 前沿拆解

长按识别二维码 · 一键关注