先看结论Agent 开发工程师并不是“会调用大模型 API、能把提示词写长一点”的岗位。企业真正要的能力是把大模型放进业务链路里让它能调用工具、读写数据、按流程完成任务同时还能被监控、被评估、被回滚。这个岗位最核心的交付物不是某个 Prompt而是一套可运行的 Agent 应用系统。这篇内容主要面向两类读者一类是从后端、全栈转过来做 AI 应用的开发者已经写过接口但对 Agent 的工程化落地还比较模糊另一类是已经在写 Agent Demo但不知道如何设计工具调用、批量任务、API 封装、性能观察和线上排查的同学。全文不会只讲概念会更偏向“企业到底怎么验收 Agent 开发”这个角度包括环境准备、最小可运行工程、工具调用设计、RAG 检索、多 Agent 编排、API 与批量任务、测试验证和排错清单。核心结论放在前面Agent 开发工程师的技术栈是“大模型 工程化 数据链路”三者交叉。模型能力只占一部分甚至不是最难的。最难的是把模型输出变成稳定、可追踪、可恢复的企业级服务。1. 核心能力速览能力项说明岗位定位基于大模型构建可运行的 Agent 应用系统负责工具调用、任务编排、接口服务、数据召回、质量评估核心语言Python 为主部分企业使用 TypeScript / Java 构建服务层关键技术Function Calling / Tool Use、RAG、提示词工程、多 Agent 编排、任务队列、可观测性模型接入方式云端 API 或本地开源模型部署具体取决于成本、数据私密性和延迟要求本地部署门槛仅调用云端 API 时不需要独立 GPU本地部署开源模型时需按模型规模和量化等级评估显存无法一概而论启动方式命令行启动开发服务、Docker 部署生产服务、任务队列异步执行批量任务接口能力通常封装为 HTTP API供前端、定时任务、上下游业务系统调用批量任务通过消息队列或异步任务框架实现例如 Celery、Redis Queue、或云厂商消息服务开发框架LangChain、LangGraph、LlamaIndex、AutoGen 等也可不用框架自研核心循环适合场景企业内部知识问答、业务流程自动化、数据查询分析、内容生成、客服辅助、代码辅助不适合场景完全不可控的高风险决策、无人工复核的金融/医疗判断、未经授权的数据采集与处理表格里的技术选型没有绑定死多数企业会混用。重点是Agent 开发工程师需要同时理解模型能力和工程约束而不是只会“写提示词”。2. 企业级 Agent 开发的能力模型2.1 思维层面从“模型返回文本”到“模型完成任务”很多初级开发刚接触 Agent 时关注的是“这个模型回得准不准”。但企业场景更关心“这个任务最终完成没有”。差异就在这模型返回一句“我已经帮你查询了订单信息”和模型真正调用订单查询接口、解析数据、把最终结果返回给用户是两回事。Agent 开发工程师的价值就是在这两者之间补齐工程链路。具体拆解思维层面需要建立三个认知第一大模型是“决策引擎”不是“数据库”。它擅长理解指令、拆解任务、判断该调哪个工具但它不适合直接存储和回复业务数据。凡是需要精确数据的场景优先走工具调用和检索而不是靠模型记忆。第二一次任务往往不是一次模型调用完成的。真实场景里Agent 可能需要先判断用户意图再决定调哪个 API拿到结果后还要二次整理甚至多次往返。这就是 Agent 循环Agent Loop的概念。第三模型输出是概率性的工程系统必须兜底。企业级 Agent 不能假设模型每次回复都成功必须设计超时、重试、校验、降级和人工介入的机制。这一点是区分 Demo 和生产系统的关键。2.2 工程层面工具链、数据流和稳定性工程能力是决定 Agent 开发工程师能否在企业里站稳的核心。先看工具链。Agent 需要调用外部能力所以开发工程师必须设计工具注册、参数校验、调用鉴权、超时控制和异常返回。工具不是你写一个 Python 函数就行而是要像设计一个微服务接口一样去设计它。再看数据流。企业 Agent 通常不是孤立服务它要接文档库、业务数据库、内部 API、用户上下文。数据从哪来、清洗成什么格式、如何切片、如何存储向量、检索结果怎么过滤这是 RAG 工程师的活但 Agent 开发工程师必须懂否则做出的 Agent 召回质量会很差。稳定性层面需要关注这几个指标单次任务的端到端耗时、工具调用失败率、流程中断后的恢复方式、并发请求下的资源消耗。批量跑 1000 条任务和单条测试跑通难度完全不是一个量级。2.3 治理层面可观测、可评估、可追溯企业级 Agent 和普通接口最大的区别是它必须有治理能力。可观测是指每次 Agent 执行的内部轨迹能被记录模型输入、模型输出、每一步调了哪个工具、工具返回了什么、最终结果是什么。没有这些日志出了问题根本无从排查。可评估是指要建立一套评测集。不能只靠“感觉回答得好”而是要准备一批典型问题、标准答案、关键工具命中条件每次改动后跑一遍回归确认没有变差。可追溯涉及合规和审计。在金融、政务、医疗等场景Agent 的每次决策都要能回溯到模型调用记录和工具调用记录。这一点实际比“模型多聪明”重要得多。3. 适用场景与使用边界企业里适合用 Agent 的场景通常有这些特征任务目标相对明确可以被拆解成步骤需要调用外部数据或工具而不是纯靠模型记忆对响应时间有一定容忍度流程可以通过日志和人工审核兜底。典型如企业知识库问答Agent 先判断问题类型再检索相关文档最后组织答案并标注来源。数据分析助手Agent 根据自然语言生成查询语句执行查询再对结果做解释。业务流程自动化例如工单分类、内容审核预处理、邮件草稿生成。研发辅助例如代码仓库问答、Code Review 辅助但必须有人工确认。不适合的场景也要说清楚高风险决策不适合全自动比如贷款审批、医疗诊断Agent 只能做辅助不能做最终判断。实时性要求极高的系统不适合把大模型放在主链路上模型推理延迟通常远高于普通接口。涉及用户隐私、商业机密的数据如果模型供应商和部署方式没有合规保障不能直接上传。这里必须强调Agent 开发工程师在接入任何业务数据、用户信息、版权内容之前要确认授权边界、数据脱敏策略和隐私保护要求。涉及人脸、声音、个人身份信息的内容更需要严格遵循合法合规要求。在企业环境里数据安全合规是红线不是可选项。4. 环境准备与前置条件4.1 操作系统与开发语言多数企业 Agent 服务运行在 Linux 环境开发机可以是 Windows、macOS 或 Linux。Python 3.10 以上是目前最通用的选择因为主流 Agent 框架对大模型生态的支持最完整。如果你所在团队技术栈更偏 Java也可以基于 Spring AI 之类的方案做但生态成熟度和示例数量目前还是 Python 更丰富。以 Python 为例建议用虚拟环境隔离依赖。python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install --upgrade pip4.2 模型访问方式环境准备里最关键的决策是模型访问方式通常有两条路第一条是调用云端大模型 API。这种方式上手最快不需要本地 GPU也不需要下载模型文件按调用量付费。适合业务快速验证、企业内部数据不敏感的初阶场景。第二条是本地部署开源模型。这种方式对数据私密性更友好但需要准备 GPU 服务器并处理模型下载、推理服务部署、显存评估和并发性能优化。显存占用量与模型参数量、量化精度、推理框架、并发数都有关系不能只看模型参数。更稳妥的判断是先用小规模测试确定显存基线再按并发数预留资源。无论哪种方式建议把模型访问封装成一个独立的接口层。例如统一封装成 OpenAI 兼容的调用方式这样后续切换模型时不需要改动业务代码。# 统一的模型客户端封装示例实际地址和密钥需要按你使用的服务配置 from openai import OpenAI client OpenAI( base_urlhttp://你的模型服务地址/v1, api_key你的密钥 ) def chat(messages, temperature0.2, max_tokens1024): response client.chat.completions.create( model你的模型名称, messagesmessages, temperaturetemperature, max_tokensmax_tokens, ) return response.choices[0].message.content4.3 依赖组件准备除了模型访问Agent 应用通常还需要以下组件向量数据库用于存储和检索文档切片常见选型有 Chroma、Milvus、Weaviate、pgvector。关系数据库或 Redis用于存储任务状态、执行记录和缓存。对象存储用于保存输入文件和处理结果。消息队列用于批量任务和解耦常见选型有 Redis、RabbitMQ、或云厂商的队列服务。日志和监控至少要有结构化日志后续可以接入监控平台。如果只是本地先做最小验证可以先只装 Chroma 和 Redis其他等到设计架构时再按需引入。5. 从最小可运行 Agent 到企业级架构5.1 先写一个最小 Agent 循环不管用不用框架理解 Agent 的核心循环比套框架重要。一个最小可运行的 Agent 循环至少包含四步模型根据用户消息和可用工具列表决定要不要调用工具以及调用哪个工具。如果模型要求调用工具代码执行对应的函数。把函数返回结果作为新的上下文交给模型。模型基于工具结果生成最终回复或者继续发起下一次工具调用。下面给一个不依赖框架的最小示例使用的包是openai和函数调用能力。为了把逻辑说清楚模型调用部分做了简化具体字段需要按实际模型服务调整。from openai import OpenAI client OpenAI( base_urlhttp://你的模型服务地址/v1, api_key你的密钥 ) tools [ { type: function, function: { name: get_order_status, description: 查询订单当前状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] def get_order_status(order_id: str) - str: # 实际开发中这里应该调用真实订单服务 return f订单 {order_id} 当前状态是已发货 def execute_tool_call(tool_name: str, arguments: dict) - str: if tool_name get_order_status: return get_order_status(arguments.get(order_id, )) return 未知工具 def agent_loop(user_message: str, max_steps: int 5): messages [{role: user, content: user_message}] for step in range(max_steps): response client.chat.completions.create( model你的模型名称, messagesmessages, toolstools, tool_choiceauto, ) message response.choices[0].message messages.append(message) if message.tool_calls: for tool_call in message.tool_calls: tool_result execute_tool_call( tool_call.function.name, eval(tool_call.function.arguments) ) messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) else: return message.content return 达到最大步骤数任务未完成 print(agent_loop(帮我查一下订单 20240001 的状态))这个示例虽然简化但已经包含 Agent 最核心的循环逻辑。实际项目里工具参数不能直接用eval要做安全的 JSON 解析和校验。5.2 判断运行成功的标准最小 Agent 能不能跑看三条模型是否正确识别出需要调用工具。工具函数是否被正确执行并且参数解析无误。模型能否基于工具返回结果给出合理回复。先不追求复杂能把这三步打通Agent 开发的基础链路就建立了。后面所有企业级能力都是在这个循环上叠加工程化措施。5.3 从最小循环到企业级架构最小循环只能说明“能跑”生产系统还必须在外面加几层。接口接入层负责接收外部请求、做身份校验和参数校验业务编排层负责任务状态管理、步骤记录和人工介入工具注册中心负责管理所有可调用工具数据检索层负责文档召回和过滤模型管理层负责模型路由、上下文组装和输出校验再往下是任务队列、缓存、日志、监控。从工程视角看Agent 系统的复杂度不在模型调用本身而在这些外围层。这也是 Agent 开发工程师岗位存在的原因模型能力再强没有外围工程层在企业里也只是个 Demo。6. 工具调用、RAG 与多 Agent 编排6.1 工具调用设计工具是 Agent 连接业务系统的桥梁。工具设计得好不好直接影响 Agent 的可用性。工具定义里描述信息非常关键。模型判断“这个任务该不该用这个工具”主要靠工具名和描述。描述要写清楚用途、参数含义、返回值格式、调用风险和失败可能。参数要尽可能合理减少模糊空间。工具返回值也要注意。企业级场景中建议固定返回结构化 JSON至少包含状态、数据和错误信息三个字段。这样模型可以基于状态码决定是否要重新调用而不是靠猜测。{ status: success, data: { order_id: 20240001, status: shipped }, error: null }同时每个工具背后是真实业务操作必须考虑鉴权、超时、幂等和审计。尤其是会写数据、改状态、发消息的工具要设计操作确认机制和操作日志。工具调用不是“写个 Python 函数”这么简单它本质上是把大模型接入了企业权限体系权限边界没控制好会产生严重风险。6.2 RAG 检索增强企业知识问答类 Agent 基本离不开 RAG。RAG 的核心链路包括文档加载、文本切分、向量化、向量存储、检索召回、结果重排、上下文组装。实际开发中文档加载和切分往往是最耗时的部分。PDF、Word、Markdown、HTML、扫描件每种格式处理方式不同。切分粒度需要根据文档结构和模型上下文长度调整没有万能的切片大小。通用做法是优先保持章节完整性再考虑固定长度切分。检索质量可以用几个基础指标判断召回结果是否包含正确答案、返回的内容是否和问题相关、是否存在大量重复片段、是否能让模型在限定上下文内生成答案。如果召回结果本身是错的后面模型回答再好也没用。所以 Agent 开发工程师要多花时间在数据清洗和切分调优上而不是只调模型提示词。6.3 多 Agent 协作与任务编排当任务链路变复杂时单 Agent 会显得力不从心。比如一个任务既要查业务库又要检索文档还要生成报表核心循环全堆在一起提示词会越来越长误判率也会上升。多 Agent 的思路是把不同职责拆给不同角色再用编排层控制流程。常见模式有三种路由模式入口 Agent 判断任务类型分发给不同子 Agent。流水线模式任务按固定顺序经过多个 Agent每个 Agent 只处理一步。协商模式多个 Agent 围绕一个目标分工协作结果汇总给主 Agent。从工程稳定性看流水线模式最容易控制也最容易被企业接受。每个节点职责单一出问题可以单独重试。协商模式虽然看起来更智能但状态管理和失败恢复成本更高初期不建议直接上。编排框架可以自己写也可以使用 LangGraph 这类工具。如果自己写核心要管理好状态、节点、边和条件跳转。如果使用框架要理解框架的状态机制不要把业务逻辑硬编码在某个节点里。7. 接口 API 与批量任务7.1 用 FastAPI 封装 Agent 服务Agent 开发最终要对外提供服务。常用方案是用 FastAPI 封装一个 HTTP 接口接收任务请求返回任务结果或任务 ID。这里有一个关键选择同步返回结果还是异步任务并轮询结果。简单场景可以同步等待Agent 跑完直接返回。但企业级场景里Agent 任务通常耗时较长动辄几秒到几十秒同步接口很容易超时。建议采用异步任务模式接口先返回任务 IDAgent 在后台执行客户端再通过结果查询接口获取进度和最终结果。from fastapi import FastAPI from pydantic import BaseModel import uuid app FastAPI() task_store {} class AgentRequest(BaseModel): user_message: str session_id: str | None None class AgentResponse(BaseModel): task_id: str message: str app.post(/agent/run, response_modelAgentResponse) async def run_agent(req: AgentRequest): task_id str(uuid.uuid4()) # 实际项目中这里应把任务交给后台 worker 执行 task_store[task_id] {status: running, result: None} return AgentResponse(task_idtask_id, message任务已接收请通过 task_id 查询结果) app.get(/agent/result/{task_id}) async def get_agent_result(task_id: str): if task_id not in task_store: return {error: task not found} return task_store[task_id]接口设计上建议把所有 Agent 请求统一封装成标准 schema包含用户输入、用户身份、会话上下文、自定义参数。不要在接口层暴露过多模型细节后续改模型、改参数才不会牵一发动全身。7.2 批量任务设计批量任务是 Agent 从“单条演示”走向“生产可用”的必经之路。批量跑一批问题对接口稳定性、模型并发、工具调用频率、上下文管理都是严峻考验。批量任务的常见实现方式有两种。简单场景可以写 Python 脚本循环调用 Agent 接口复杂场景要引入消息队列。队列的好处是流量可以削峰填谷任务失败可以重新入队而且方便做并发控制和进度统计。批量任务至少要记录以下内容任务 ID、输入内容、执行状态、耗时、失败原因、输出结果。跑完一批任务后要能快速查看成功率、平均耗时和常见失败类型。没有这些数据批量优化就是盲人摸象。# 伪代码示例批量任务循环调用需要根据实际接口调整 import requests api_url http://127.0.0.1:8000/agent/run result_url http://127.0.0.1:8000/agent/result/ with open(batch_inputs.txt, r, encodingutf-8) as f: questions [line.strip() for line in f if line.strip()] for i, question in enumerate(questions, start1): resp requests.post(api_url, json{user_message: question}, timeout30) task_id resp.json()[task_id] print(f任务 {i}: {task_id}) final_result None for _ in range(60): result_resp requests.get(result_url task_id, timeout10) status result_resp.json().get(status) if status finished: final_result result_resp.json().get(result) break time.sleep(1) print(f任务 {i} 结果: {final_result})批量任务最容易踩的坑是单条跑通后直接跑全量结果跑到一半接口超时、工具调用报错、内存涨满。所以批量前一定要设计好失败重试、断点续跑和异常隔离。一批任务分片处理每片跑完记录进度中断后从上次进度继续。8. 功能测试与效果验证8.1 测试维度Agent 的测试比传统后端接口复杂得多。传统接口测试是确定性的输入相同输出相同Agent 测试是概率性的同样的问题模型可能给出不同回答。所以 Agent 测试一般从以下几个维度评价。第一是意图理解模型能不能正确理解用户任务场景切换时是否混乱。第二是工具选择模型该调工具的时候会不会调不该调的时候会不会乱调。第三是参数提取模型能不能从用户输入里正确抽取工具参数漏一项后面就会报错。第四是结果可靠性工具返回数据后模型能不能准确转述会不会凭空添加数据。第五是边界情况输入缺失、输入异常、多轮对话、上下文超长、模型输出格式错误都要测试。8.2 评测集与回归建议每一个 Agent 项目都建立一份评测集哪怕刚开始只有几十条。每条评测要包含用户输入、预期行为、预期调用的工具、关键输出要点、通过标准。模型更新、提示词调整、工具定义变化之后都要回归跑一遍评测集。通过率下降就要分析是模型能力变化还是工具描述不够清楚还是评测本身不合理。8.3 稳定性验证稳定性测试重点是反复跑同一批任务观察失败率和耗时分布。常见现象是单次调用正常但连续调用后开始报错。原因多集中在上下文无限增长导致超出模型长度限制、工具并发调用超限、内存和显存持续上涨、上游 API 触发限流。稳定性测试要有意识地连续跑几十上百条任务而不是只测一两条。测试过程中要记录每轮调用的 token 数、耗时、工具调用次数和异常类型。这些数据是后续优化最直接的依据。9. 资源占用与性能观察9.1 Token 消耗Agent 的 token 消耗和单次模型问答完全不是一个量级。一次 Agent 任务可能包含多次模型调用每次调用都会把历史记录、工具描述、工具返回结果重新发给模型。上下文越长token 消耗越大响应越慢成本越高。观察 token 消耗要区分输入 token 和输出 token。输入 token 主要取决于系统提示词长度、工具定义长度、历史消息长度、检索内容长度。输出 token 取决于模型生成答案的长度。优化方向有几个精简系统提示词工具描述只保留关键信息避免长篇大论历史消息做截断或摘要检索结果只保留和问题最相关的片段。别小看这些优化一个频繁使用的 Agenttoken 成本优化后差距可能是一倍以上。9.2 响应延迟Agent 的端到端延迟几乎是所有耗时的累加模型推理时间、工具调用时间、检索时间、多个步骤串行时间。步骤越多延迟越高。如果接口要求 3 秒内返回但 Agent 一次任务需要 10 秒那就必须改架构。可以优化模型推理速度换成更快的小模型可以缩短上下文减少输入 token可以并行执行多个独立工具调用也可以用异步任务模式先返回任务 ID让前端轮询结果。9.3 显存与 CPU如果使用本地部署的模型显存占用是核心关注点。显存占用高低主要取决于模型参数量、量化精度、推理框架、并发请求数、上下文长度。给你一个更稳妥的判断方法先在单并发下测试显存基线再逐步增加并发观察显存增长曲线最后按业务峰值预留富余。不要轻信网上传的“某个模型多少 G 显存能跑”因为实际占用和推理参数关系极大。如果显存不足可以换更小参数量的模型、提高量化等级、缩短上下文长度、限制并发数。如果完全没有 GPU 资源也可以先用 CPU 推理做功能测试但生产环境的性能建议以实际压测为准。9.4 进程与端口管理多个 Agent 服务、模型推理服务、向量数据库同时运行时端口和进程管理是个容易被忽略的坑。启动前先检查端口占用避免多个服务抢占端口。批量任务跑完要确认进程正常退出避免残留进程占住内存。模型推理服务如果长期运行注意观察显存是否被积压请求占满必要时设置服务重启策略。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型不调用工具直接凭记忆回答工具描述不清晰、模型不支持工具调用、工具列表未传入查看请求日志确认 tools 参数是否传入单独测试模型工具调用能力优化工具描述更换支持工具调用的模型工具参数解析报错模型生成的参数是非法 JSON、参数类型不匹配打印模型返回的原始 arguments查看具体内容增加 JSON 解析容错在工具定义中明确参数类型和枚举值多轮对话后回答质量明显下降上下文过长、历史记录过多无效信息检查每轮调用发送的 token 数量和内容历史消息截断或摘要只保留和当前任务相关的上下文Agent 任务耗时过长步骤过多、单步模型延迟高、工具调用慢在日志中统计每个步骤耗时并行化独立工具调用减少不必要步骤换更快模型批量任务跑到一半失败接口超时、模型限流、工具调用失败、内存增长查看批量任务日志统计失败任务分布增加失败重试任务分片处理增加超时和熔断本地模型显存溢出模型参数量过大、并发过高、上下文过长观察推理服务日志和显存监控记录溢出时上下文和并发降低并发缩短上下文换量化等级更高的模型检索到的文档和问题不相关文本切分不合理、向量模型效果不足、召回策略太简单检查召回结果分析失败问题类型优化切分粒度调整召回条数引入重排序模型回答里出现编造数据模型未正确读取工具返回结果、上下文被无关内容干扰查看工具返回结果是否被完整传给模型强化提示词指令让模型只基于工具结果回答禁止猜测多个服务端口冲突服务默认端口相同查看启动日志和系统端口占用修改服务端口统一管理端口分配以上问题在 Agent 开发中非常典型。排查思路的核心是先看日志把模型调用记录、工具调用记录、检索记录拆开定位哪一层出问题就修哪一层不要一上来就改提示词。11. 最佳实践与使用建议11.1 先明确验收标准再做任务拆分写 Agent 代码之前先和业务方对齐一个问题“这个 Agent 做到什么程度算成功”是回答准确率达到多少是任务完成率达到多少还是单次任务成本控制在多少验收标准不明确后续优化就是无底洞。11.2 保留一套最小可运行配置Agent 项目依赖组件多模型服务、向量库、Redis、业务接口都有可能挂。建议把最简启动方式写成脚本记录依赖版本和启动顺序。出问题时可以在干净环境快速重建。11.3 工具权限最小化Agent 能调用的工具、数据、操作权限必须按最小必要原则控制。能只读就不要开放写操作能限定范围就不要开放全量。每个工具调用都要写入审计日志尤其是涉及修改数据、发送消息、调用外部服务的操作。11.4 批量任务加日志和断点续跑批量任务不要只输出最终结果每一个任务的输入、输出、状态、耗时、失败原因都要记录下来。批量任务要支持断点续跑避免中途挂了全部重跑。建议把执行进度和结果存到数据库或文件方便分析和恢复。11.5 涉及敏感内容必须授权和复核这是重中之重如果 Agent 涉及人脸、声音、个人隐私、版权素材、内部商业信息必须确认授权、脱敏方案和合规边界。企业里做 Agent数据安全合规不只是一个流程问题更是法律和信任问题。不要为了演示效果绕过权限控制或私自收集数据。11.6 发布前做效果复核模型更新、提示词调整、工具改动后都要跑一轮评测集。生产环境发布要有灰度方案先用小流量观察确认正常后再全量放开。Agent 应用不同于普通后端服务它的行为概率性很强灰度越充分线上事故越少。12. 总结与下一步Agent 开发工程师最值得投入的方向不是追最新的模型框架而是把最小 Agent 循环跑通后把工具调用设计、RAG 检索、批量任务、接口服务、日志监控和评测回归这些工程能力一步步补齐。企业里真正缺的是能把大模型放进业务链路并稳定运行的人不是只写提示词的“大模型用户”。建议你先从三件事开始第一写一个最小 Agent 循环跑通“模型决策-工具调用-结果返回”的基本链路第二选择真实业务场景给 Agent 接两个工具比如查数据库和检索文档第三建立一份评测集把这个场景的通过率量化出来。哪怕评测集只有 30 条也比“感觉效果不错”靠谱得多。最容易踩的坑有三个一是把 Agent 当成数据库指望模型记住数据二是工具设计过于随意模型想调却调不对三是没有评测和日志直接上线出了问题无从下手。后续可以继续扩展的方向多 Agent 协作的任务编排、更细粒度的评测体系、基于反馈的自动优化、模型路由与成本控制。这个岗位的技术边界还在快速变化但工程化的基本功不会过时。建议把这几项能力按顺序打磨收藏备用。
