AI Agent开发实战：从最小可用代码到接单交付的完整路径

最近大半年，我被问得最多的问题就是：AI Agent开发是不是真的成了最赚钱的编程方向？动不动就听到月薪3到8万的说法，各种社群里全是类似的标题，好像只要学会写Agent，钱就会自己往口袋里跑。我没法向你保证某个夸张数字一定会落到你头上，但可以负责任地说：这个方向的机会是真的，只是机会的形状和你想象的不太一样。

这篇文章我想以实际动手做项目的人的视角，聊聊AI Agent开发到底在开发什么、新手容易在哪儿翻车、一个最小可用的Agent代码长什么样、以及从“自己能跑通”到“别人愿意付钱”之间还差哪几步。标题里的“附源码”和“接单渠道”我也会给出实操层面的答案，但不打算再用“包教包会、月入几万”的口气说话——那种话除了让你冲动付费，没什么用。

1. AI Agent开发为什么突然成了高薪方向：先看市场供需

1.1 需求端：企业真正要买的不是“模型”，是“可控的自动化”

很多人觉得AI Agent开发就是“调大模型接口”，这理解不能说错，但完全不在同一个量级上。企业客户真正头疼的问题是：我已经买了大模型API，也试过让员工用对话窗口处理业务，但结果没法固化到流程里。员工问一次可以，天天问不行；模型答得对的时候很好，答错的时候没人知道；一个任务涉及公司内部系统时，模型根本够不到那些数据。

于是“Agent开发”成了那个把大模型从聊天窗口里捞出来、塞进业务流程的人干的事。你要做的是让模型不再只是回答问题，而是面对一个目标，自己拆解步骤、调用工具、检查结果、修正错误、最后给出可用的产出。企业为此付费，本质是在买“确定性和可控性”——模型本身是概率性的，但通过工程手段把它约束在业务规则里，让它输出稳定、可追溯、可回滚。这件事有价值，而且目前真正能做好的人不多。

1.2 供给端：会调API的人和能交付Agent的人是两种物种

现在市面上的普通开发者和AI爱好者，大多数停留在“会调大模型API”的阶段，也就是今天给一段Prompt，明天换一个模型，后天调一下温度参数。真正能交付Agent的人需要同时具备三块能力：第一是工程能力，得懂异步任务、消息队列、状态管理、异常兜底；第二是模型能力，要知道什么样的问题该用思维链、什么样的问题该调用工具而不是让模型硬答；第三是业务能力，得能把客户的模糊目标翻译成一套可执行的工具函数和数据协议。

这三块能力叠在一个人身上，供给自然稀缺。我可以给你一个比较直观的判断：一条招聘或外包需求发出来，真正能完整走完“需求梳理→工具设计→Agent编排→测试交付”的人，可能只占应征者的两成不到。薪资被推高是供需关系的结果，不是谁在制造焦虑。

1.3 3-8万的薪资数字是怎么构成的

标题里那个3-8万，需要拆开看。达到这个收入的人，通常不是靠某个单一指标的“工资”，而是几种结构的叠加：第一种是做远程技术顾问，按项目阶段收固定费用，月度结算，类似外包的技术负责人；第二种是做按项目交付，一单几万，一个月能并行两三个小项目；第三种是把自己做的Agent封装成某个小场景的SaaS服务，按订阅收费，这个上限更高但周期更长。

这三种形态对应的能力要求都不低于“能写出一个Demo”。所以我的建议很直白：如果你刚接触这个方向，不要盯着“3-8万”这个结果，要去够那个结果背后的能力组合。能力到了，收入是自然的结果；能力没到，再高的标题也只是标题。

2. 新手最常踩的三个坑：在动手写第一行代码前先改掉

2.1 把Agent当成“在循环里反复调大模型”

我见过很多初学者写的“Agent”，本质就是一个while循环：调大模型，拿到回复，再调大模型，偶尔把上一轮结果拼进Prompt，然后祈祷这次回答更准确。这种实现的唯一作用是消耗Token，顺便让自己产生一种“我在做AI”的错觉。

真正的Agent必须有清晰的闭环：接收目标之后，先判断自己手里有哪些工具，缺什么信息就调什么工具，工具返回结果后，模型再基于新的信息决定下一步做什么。这个循环要有限制、有日志、有退出条件，而不是无脑转圈。你可以把Agent想象成一名新员工：他得知道自己有哪些权限、哪些信息能查到、查完之后该做什么、遇到查不到的情况向谁求助。如果你给新员工的只有一张嘴和一台没有权限的电脑，那他什么都干不成。

2.2 工具调用的契约没设计清楚，上下文迟早爆掉

第二个高频坑是只关心“让模型能调用工具”，不关心“工具怎么被正确调用”。工具的本质是函数，函数就得有明确的入参、出参、异常返回。你要在系统提示词里告诉模型：这个工具接收什么格式、哪些是必填项、返回结构是什么、失败会返回什么。

举个最典型的翻车现场：工具返回了一长串原始数据，模型把这些数据原封不动全部塞回上下文，下一轮调用时上下文已经几万字了，费用翻倍不说，模型注意力也被带偏。我在实际项目里的做法是，工具返回前先做一次结构化压缩，只回传“当前任务真正需要的摘要”，甚至提前截断。这个细节你不在生产环境里被账单吓一跳，是很难意识到的。

2.3 没有评测体系，全凭感觉调Prompt

最后一个坑，也是最隐蔽的：很多人改Prompt靠“这次不行再试一次”，没有评测集，没有回归测试。你今天改了一版提示词，连着测三条感觉不错，就上线了；结果明天用户换了种表达方式，Agent就开始乱来。

正确的做法是建一个最小评测集，几十条真实输入即可。每次改动提示词或工具逻辑之后，统一跑一遍，看正确率是上升还是下降。没有评测体系，你所谓的“优化”大概率只是让某些案例变好、另一些悄悄变坏，而你根本不知道。这一点我会在第四章展开讲，因为它就是把Demo变成交付物的分水岭。

3. 一个最小可用Agent的完整实现：模块拆解和核心代码

3.1 先画出最小闭环：计划-执行-观察-再计划

在写代码之前，先把闭环画清楚。一个最小可用的Agent，至少要包含四个角色：任务输入、模型决策、工具执行、结果回填。模型是“大脑”，工具是“手脚”，上下文就是“工作台”。每一轮循环里，模型决定调哪个工具、传什么参数；工具执行完，把结果作为新的消息追加到上下文；模型看到结果后决定继续调用还是给出最终答案。

我建议把循环步数上限设死，比如最多6步，防止模型进入死循环。这不仅是成本保护，也是行为约束——真实世界里也没有人能无限重试。

3.2 代码骨架：LLM接入、工具注册、主循环

下面这段代码是一个不依赖任何第三方编排框架的最小实现，只用了Python标准库和HTTP请求。你只需要把其中调用大模型的部分替换成自己手上的服务商接口。

import json from typing import Callable, Dict, Any # ---------- 工具注册表 ---------- TOOLS: Dict[str, Callable] = {} TOOLS_META: Dict[str, dict] = {} def register_tool(name, description, params_schema): def decorator(f): TOOLS[name] = f TOOLS_META[name] = { "type": "function", "name": name, "description": description, "parameters": params_schema, } return f return decorator @register_tool( "query_order_status", "查询订单当前状态，按订单号精确匹配", { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"} }, "required": ["order_id"], }, ) def query_order_status(order_id: str) -> str: # 这里演示用，实际项目请替换为数据库或接口查询 return json.dumps({"order_id": order_id, "status": "已发货"}, ensure_ascii=False) # ---------- LLM 调用 ---------- def call_llm(messages, tools_meta=None): # 替换为你的服务商接口地址、密钥和模型名 # 这里省略 HTTP 请求细节，只描述返回结构 raise NotImplementedError("请填入你使用的大模型API") # ---------- 工具调度 ---------- def execute_tool(name: str, args: dict) -> str: if name not in TOOLS: return json.dumps({"error": f"未知工具: {name}"}, ensure_ascii=False) try: return TOOLS[name](**args) except TypeError as e: return json.dumps({"error": f"参数错误: {str(e)}"}, ensure_ascii=False) except Exception as e: return json.dumps({"error": f"执行异常: {str(e)}"}, ensure_ascii=False) # ---------- Agent 主循环 ---------- def run_agent(user_task: str, max_steps: int = 6) -> dict: system_prompt = "你是一个任务助手。根据用户请求，判断是否需要调用工具。" messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_task}, ] for step in range(max_steps): resp = call_llm(messages, [TOOLS_META[k] for k in TOOLS]) if resp.get("finish_reason") == "stop": return {"success": True, "answer": resp.get("content"), "steps": step + 1} tool_calls = resp.get("tool_calls", []) if not tool_calls: # 模型没要求调用工具，但也没结束——直接把它的话当消息记录 messages.append({"role": "assistant", "content": resp.get("content")}) continue # 把模型发出的工具调用请求写入上下文 messages.append({ "role": "assistant", "content": None, "tool_calls": tool_calls, }) # 逐个执行工具，把结果以 tool 消息回填 for tc in tool_calls: result = execute_tool(tc["name"], tc["arguments"]) messages.append({ "role": "tool", "tool_call_id": tc["id"], "content": result, }) return {"success": False, "error": "超出最大步数"}

3.3 实例演示：工单分类Agent怎么跑通

我用一个最常见的“客服工单分类和拟回复”任务来演示整个闭环。工具包括：查订单状态、查知识库文章、给工单打标签。用户输入：“客户说订单A10086三天没发货，问什么时候能到，帮我处理一下，再写一段安抚回复。”

Agent走了三拍：第一轮，模型决定调用查询订单状态和知识库文章两个工具；第二轮，拿到结果后发现订单状态是“已发货”，只是物流信息未更新，于是调用打标签工具；第三轮，模型综合信息，生成最终回答。整个过程每一步都被记录在消息列表里，可追溯，出了问题能逐帧回放。

3.4 这段代码为什么会失败：新手最容易忽略的运行细节

上面这段代码我在参加技术社群时给不少人看过，他们跑起来之后最常见的问题有三个。

第一，tool_calls里的arguments是JSON字符串，不是对象。很多模型返回的时候会转义或者带换行，直接**args会炸，必须先json.loads再解析。第二，服务商的finish_reason名称并不统一，有的是stop，有的是end_turn，有的是tool_calls——你写代码时不要硬编码我要用的词，先打印一次真实响应看看字段再定。第三，要区分“模型说没有工具可调”和“模型没说结束”这两种情况，前一种可以继续追问，后一种要设置兜底，防止它一直空转。

另外补充一个和后面接单有关的心得：这些细节正是项目经理和普通开发者的差距所在。客户不会关心你用了什么框架，他们只关心“这个Agent上线之后会不会半夜因为一条异常数据就崩掉”。这些问题你越早踩过，在客户面前就越值钱。

4. 把Demo变成可交付项目：四个工程化改造点

4.1 输入输出协议固定，别让Agent自由发挥字段

Demo阶段的Agent输出是“自然语言”，怎么都行；交付阶段的Agent输出必须是“结构化协议”。客户接你的Agent，绝大多数不是为了和它聊天，而是要把它接到自己的系统里。所以开工第一天就要定义清楚：入参是什么格式、出参是什么格式、错误码有哪些。

我列一个小表格，可以当作交付协议的模板：

你可能会觉得这有点小题大做，但真实项目里最大的返工来源就是字段对接。先固定协议，后面所有环节都顺。

4.2 状态与记忆持久化：中断了还能接着跑

Demo里，Agent的所有上下文都放在内存变量里，程序一重启就什么都没了。交付项目不行，尤其是跑批任务的Agent，走到第三步挂了，总不能从头再来。

至少要做到三件事：把每轮消息持久化到本地文件或数据库；记录当前执行步数和所处阶段；支持从某个step恢复继续跑。这一步的工程量和收益比很高。我见过不少团队，Agent在试验环境表现完美，一上生产就频繁超时，最后发现是状态没持久化、每次重试都是全新上下文，模型根本不知道前面做过什么。

4.3 异常与超时处理：生产环境看的是兜底能力

模型调用有超时，工具执行有异常，外部接口有流量限制，这些在Demo里你往往不会碰到，因为一次就几个请求。到了交付阶段，这些全部是必答题。

我的经验是给每个外部依赖都包一层超时和重试策略：超时时间、重试次数、退避间隔，以及重试N次后仍失败的降级返回。所谓降级返回，就是给模型一个明确的信号：“这个信息暂时查不到，请基于现有信息完成你的回答，并明确告知用户哪部分信息缺失。”这个兜底能力决定客户敢不敢把Agent开到真实流量里。

4.4 建一个20条的小评测集，每次改动都回归

我在前面说过评测体系，这里具体展开。交付之前，从客户的真实数据里抽20条典型输入，覆盖正常情况、边界情况和异常情况，做成评测集。每次修改提示词、调整工具、升级模型，统一跑一遍这20条，看有没有回归劣化。

这里有个容易被忽视的技巧：每条评测除了记录“最终答案对不对”，还要记录“中间路径对不对”。比如某条任务应该先查订单再查知识库，结果模型先查了知识库再查订单，虽然最终答案碰巧对了，但路径是错的，这种也要标记出来。因为路径错了，将来遇到稍微复杂一点的任务，结果很快就会不稳定。

5. 新手接单的正确姿势：渠道、报价与交付边界

5.1 第一单从哪里来

接单这件事，我不建议什么都试。新手最容易犯的错是在大型外包平台上和一堆人卷低价，最后报出的价格连购买大模型API的账单都覆盖不了。更合理的路径有三个：第一，在开源社区和开发者社群里持续发“Agent落地方案复盘”，把你在第三章做的那个工单分类Agent写成带截图、带代码、带踩坑记录的文章，很多中小企业主会主动找上门；第二，找你身边做独立开发、做外包的朋友，他们手里经常有“帮客户做个内部知识库问答”这种活，需要懂Agent的人合作；第三，在一些自由职业平台搜索“自动化办公”“流程智能化”这类需求，这类需求用词不一定是Agent，但本质全是Agent。

我的个人经验是，第一单的价格不重要，重要的是形成可展示的案例。有了一个真实的客户背书，后续报价可以直接翻倍。

5.2 按价值报价，不按小时报价

接单新手特别喜欢按小时报价，但按小时报价有个天然劣势：你会被客户的预期绑定，“我付了10个小时的钱，你怎么还没做完”。正确的报价方式是按交付物拆价。

举个例子，一个“自动整理销售日报并生成周报”的需求，你可以拆成：数据接入与清洗（8000）、Agent流程与工具设计（12000）、管理后台与人工审核界面（8000）、测试与部署培训（5000）。总价三万三。客户看到的是每个模块对应什么结果，而不是你干了多少小时。

当然，报总价的前提是你自己心里要有一个大概的工时估算。我通常会把计划工时乘以1.8再报总价，因为Agent类项目最大的特点是“看着快，真正调稳定很慢”。

5.3 接单前必须问清楚七个问题

在接任何Agent项目之前，我都会先问客户七个问题，答不上来的项目直接放弃，省得更难受：

1. 任务的输入来源是什么？是文件、系统接口，还是人工录入？
2. 输入数据的量级和格式是否稳定？有没有脏数据和异常格式？
3. 输出结果给谁用？是直接面向C端用户，还是内部人员审阅后使用？
4. 如果Agent判断出错，最严重的后果是什么？什么场景下需要人工介入？
5. 数据涉及哪些系统和权限？Agent能不能直接访问？
6. 有没有历史数据可以做评测集？至少提供20条真实案例。
7. 客户预期的交付形态是API接口、定时任务脚本，还是带界面的工具？

这七个问题里，第四个最容易被忽视。如果Agent的输出直接就给终端用户看不经人工审核，那你的报价里必须包含极大量的测试和兜底逻辑，价格完全不是“做个Demo”的事。

5.4 交付物清单：别只交一段代码

前面说的都是准备工作，真正交付时你给客户的不应该只是代码文件，而是一个完整的交付包，至少包含：源代码仓库、部署文档、环境配置说明、评测集和测试报告、使用说明，以及一份“已知边界清单”。

“已知边界清单”很重要。你要主动告诉客户，当前的Agent在哪些场景会处理不了、哪些输入会导致结果不准、哪些操作需要人工复核。表面上这是在“自曝其短”，实际是保护自己。否则客户后面遇到任何问题，第一反应都是“你写的Agent有问题”，而不是“我们当时没约定边界”。

6. “月薪3-8万”的真实拆账：三种收入形态与前三月的预期

6.1 三种拿到钱的形态

接单做到后面，收入通常会长成三种形状的某一种或组合。

第一种是“远程技术顾问”，你服务三五家固定的甲方，按月度服务费收取，价格可以压到一个月2-4万，好处是稳定，坏处是每家客户的需求五花八门，你需要有很强的边界管理意识。

第二种是“项目制交付”，专注做某一个细分场景，比如“企业内部的发票信息提取Agent”“自动化报表生成Agent”。这类项目单价在2-8万之间，做熟了边际成本很低，甚至可以抽出一部分转包给别人做。

第三种是“垂直工具订阅”，把Agent产品化成一个小而美的SaaS。这条路前期最苦，但后面最轻松。我认识的一位开发者把某类表单审核流程做成了订阅产品，每月收入反而超过了做定制项目。

6.2 新手前三月的合理预期

我不会给你画饼。现实情况是，多数零基础扎进来的人，前三个月真正能完成的是：学懂循环、工具调用、上下文管理这三大核心机制，做出两三个能跑的Demo，用低价甚至免费帮一两个人解决真实问题，积累第一份项目复盘。能在这个阶段谈到第一笔付费订单，已经跑赢了大多数人。

要注意的是“低价”不等于“白送”。哪怕第一次只收两千块，也要签一个最简单的合作说明，明确需求、交付内容和边界。这会从一开始就帮你和客户建立专业协作关系。

6.3 我的时间分配建议与最后的心里话

最后说一点个人的时间分配建议：不管你是在职还是全职投入这个方向，把学习和交付之外的时间留一块给复盘和写文章。我见过所有能持续拿到好价格的人，没有一个是不写东西的。写文章不是自嗨，它是在训练你把踩过的坑结构化，也让潜在的客户能搜到你。

如果你问我现在入行还早不早，我的判断是不晚，但窗口期不会永远开着。真正值钱的不是“我会调API”这个动作，而是“我能让大模型在真实业务里稳定干活”这个结果。希望这篇拆解能让你少走点弯路，也更清楚自己接下来该补哪块能力。