如果只看过去两年的技术热点大模型刚火起来的时候我们讨论的是“提示词怎么写”2024年大家开始关注 RAG、向量库和模型微调而到了 2025 年整个行业的风向几乎一致地落在同一个词上Agent。从 Claude 的 Computer Use到 OpenAI 的 Operator再到各类开源框架 LangChain、AutoGPT、MetaGPT 层出不穷工具链越来越丰富但问题也随之而来——Agent 到底能不能稳定落地多 Agent 协作到底怎么设计才不失控Agent 的评测、安全和成本控制怎么做这些问题已经不是写几个 Demo 就能回答的了。AGNTCon 把场子定在阿姆斯特丹九月举办从公开信息看这是一个专注 AI Agent 技术和工程落地的技术会议。在大量 Agent 项目都还停留在“演示很好、生产不行”的阶段这种把工程问题放在台面上讨论的会议反而比那些追逐新模型的发布会更值得开发者关注。这篇文章不打算做会议日程的搬运工而是想借“AGNTCon 阿姆斯特丹九月阵容公布”这个节点聊聊 Agent 技术真正到了什么阶段、开发者应该关注哪些核心问题并给出可直接运行的 Agent 开发示例和排错方法帮助你在阅读会议相关内容时有一张自己的技术地图。1. 为什么 Agent 技术在 2025 年迎来工程化拐点过去一年很多人对 Agent 的认知经历了从狂热到怀疑再回到理性的过程。2024 年初AutoGPT 刚出现的时候大家都觉得大模型已经能自己拆解任务、自己写代码、自己执行了AGI 似乎近在眼前。后来大家发现这类项目跑简单任务还行一旦进入真实业务场景就经常出现任务拆解不合理、工具调用失败、上下文越来越长、错误不断累积等问题。于是又有人说 Agent 是个伪需求不如老老实实用 RAG 和流程编排。这两种判断其实都过于极端。从技术演进的角度看Agent 的意义不在于“一次搞定复杂任务”而在于它把大模型的使用方式从“一次问答”变成了“一个可规划、可执行、可反馈的系统”。单次对话再聪明也只能回答你问的问题而 Agent 可以自己拆解问题、调用工具、修正路径、完成多步骤目标。这个能力差异是结构性的不会因为某个 Demo 失败就消失。真正让 Agent 在 2025 年走到工程化拐点的是几个基础条件的成熟。第一模型的能力已经足够支撑复杂推理。当前主流模型的指令跟随、代码生成、长上下文理解和工具调用能力已经比两年前有了数量级提升。模型不再是 Agent 系统的瓶颈至少在很多业务场景里不是。第二工具调用协议逐步标准化。从最早的 Function Calling到现在的 MCPModel Context Protocol工具层正在变成“插拔式”的生态。Agent 不再需要为每一个 API 写单独的适配器。第三基础设施开始补齐。Agent 的运行需要记忆管理、状态持久化、任务队列、可观测性、权限控制。这些在过去都靠开发者自己拼装现在主流框架已经在提供标准化的组件。AGNTCon 选择在这个时间点办一场纯 Agent 主题的技术会议本质上就是行业开始从“概念验证”转向“生产落地”的信号。对于开发者来说这是一个值得投入精力的方向但前提是要用工程化的思路去学习而不是继续停留在“调 API 写提示词”的层面。2. Agent 的核心概念与系统架构要理解 Agent 工程化首先得建立一套清晰的概念框架。我们通常说的 Agent可以拆成两层来理解一层是“大脑”也就是大语言模型另一层是“身体”也就是工具、记忆和执行环境。一个完整的 Agent 系统至少包含以下五个部分组件作用对应实现模型Model负责推理、规划、生成Claude、GPT、通义千问、DeepSeek 等指令Prompt/System定义 Agent 的角色、能力边界和工作流程System Prompt工具Tools让 Agent 能与外部世界交互API 调用、代码执行、搜索、数据库操作记忆Memory保存短期上下文和长期知识上下文窗口、向量数据库、结构化存储执行与反馈Executor/Feedback执行动作并观察结果决定下一步ReAct 循环、任务队列、反思机制用大白话说用户提出一个目标Agent 先把目标拆成若干子任务然后根据每个子任务选择调用合适的工具执行后观察结果如果偏离预期就调整方案最终完成目标。这个“思考—行动—观察”的循环是 Agent 最核心的运行模式。很多人容易把 Agent 和 Workflow 混在一起这里需要区分清楚。Workflow 是预设好的流程节点和分支在开发阶段就固定了。比如一个订单审核流程先校验参数再查库存然后调支付每一步都是写死的。Agent 则不同它在运行时才决定调用哪些工具、使用什么顺序。Workflow 强调确定性Agent 强调灵活性。这个区别决定了它们各自的适用场景如果业务流程固定、步骤清晰、错误模式已知优先用 Workflow不要强行上 Agent。如果流程有大量分支选择、需要根据中间结果动态调整、高度依赖自然语言理解再考虑 Agent。很多项目失败就是在这层选择上出了问题。把本可以用 Workflow 解决的问题包装成 Agent只会引入更多不确定性增加维护成本。3. Agent 开发环境准备与前置条件无论你是从零学习 Agent还是准备在项目中引入 Agent先花时间把环境准备好会省下大量排错时间。我推荐至少准备以下环境开发语言Python 3.10 或更高版本。当前大多数 Agent 框架和 AI SDK 都以 Python 为第一优先支持语言生态最完整。Python 环境管理推荐使用uv或conda避免全局环境混乱。模型访问权限需要一个支持 Function Calling 或 Tool Use 的大模型 API。重点确认你的模型服务商是否支持tools参数。基础依赖常见的 Agent 开发库包括 LangChain 或 LlamaIndex以及requests、pydantic等基础设施库。可选工具Docker用于本地运行 MCP Server 或隔离工具执行环境。版本问题请注意当前 Agent 框架迭代非常快指南中出现的版本号可能很快过时所以本文将使用通用 API 风格不绑定死某个版本。你在实际操作时以官方文档为准。最小化安装示例在终端执行# 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装基础依赖 pip install requests pydantic openai langchain-core # 安装完成后查看版本确认环境正常 python -c import openai; print(openai.__version__)如果没有特别多的历史包袱我更推荐直接用uv来管理环境速度更快依赖解析也更干净uv venv .venv uv pip install requests pydantic openai langchain-core环境准备好之后建议先跑通一个最简单的对话调用确认 API Key、网络和服务商配置都正常再进入 Agent 开发。这样后续排错时可以把“模型调用问题”和“Agent 逻辑问题”隔离开。4. 从零写一个最小 Agent核心流程拆解很多人学习 Agent 的第一个误区是想直接上手复杂框架。我更推荐先理解 Agent 的最小闭环再去看框架。一个最小 Agent 只需要做四件事接收用户目标。让模型判断需要调用哪些工具。执行工具并返回结果。把结果交还给模型让它决定下一步。理解这个循环最好的方式是自己实现一遍哪怕只支持一个工具。这里我们实现一个“能查询当前时间并做出回答”的 Agent。首先看文件目录结构方便你对照minimal_agent/ ├── agent.py └── tools.pytools.py定义工具函数# 文件路径minimal_agent/tools.py 工具定义模块所有 Agent 可以调用的工具都放在这里。 from datetime import datetime def get_current_time(location: str UTC) - str: 获取指定时区的当前时间。 这里为了演示保持简单只处理 UTC 和 Asia/Shanghai 两个时区。 实际项目中应该接入真实的时间服务或第三方 API。 Args: location: 时区名称如 UTC 或 Asia/Shanghai。 Returns: 当前时间的字符串表示。 if location UTC: return datetime.utcnow().strftime(%Y-%m-%d %H:%M:%S) if location Asia/Shanghai: # 简单模拟上海时间比 UTC 快 8 小时 return datetime.utcnow().strftime(%Y-%m-%d %H:%M:%S) 0800 return 暂不支持该时区注意上面代码里有一个简化的实现实际项目中请使用zoneinfo或第三方库处理时区而不是拼接字符串。这样演示的重点放在“工具如何被编排”而不是时间服务的实现上。agent.py是 Agent 主循环# 文件路径minimal_agent/agent.py 一个最小可运行的 Agent 示例。 它演示了 Agent 的核心循环 1. 将用户目标发送给模型 2. 模型判断需要调用哪个工具返回结构化调用参数 3. 执行工具 4. 将结果返回给模型得到最终回答 import json import os from openai import OpenAI from tools import get_current_time # 工具注册表Agent 在执行时需要根据模型返回的名称找到对应函数 TOOL_REGISTRY { get_current_time: get_current_time, } # 工具描述模型通过这段 JSON 描述理解工具的作用和参数 TOOLS [ { type: function, function: { name: get_current_time, description: 获取指定时区的当前时间, parameters: { type: object, properties: { location: { type: string, description: 时区名称如 UTC 或 Asia/Shanghai, } }, required: [location], additionalProperties: False, }, }, } ] def run_agent(user_query: str) - str: 运行 Agent 主循环。 这是一个简化版本只处理一轮工具调用。 生产环境中的 Agent 可能需要多轮迭代需要增加循环和终止条件。 client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) messages [ { role: system, content: 你是一个智能助手可以通过工具获取当前时间然后回答用户的问题。, }, {role: user, content: user_query}, ] # 第一次请求带 tools 参数 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, ) first response.choices[0].message # 如果模型没有要求调用工具直接返回文本 if not first.tool_calls: return first.content or 模型未返回内容 # 模型要求调用工具遍历每个调用 tool_call first.tool_calls[0] function_name tool_call.function.name arguments json.loads(tool_call.function.arguments) print(f模型决定调用工具: {function_name}) print(f工具参数: {arguments}) # 从注册表找到并执行工具 function_to_call TOOL_REGISTRY[function_name] tool_result function_to_call(**arguments) # 把工具执行结果加入消息列表 messages.append(first) messages.append( { role: tool, tool_call_id: tool_call.id, content: tool_result, } ) # 第二次请求模型基于工具结果生成最终回答 second_response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, ) return second_response.choices[0].message.content or 模型未返回内容 if __name__ __main__: # 需要先通过环境变量配置 API Key if not os.getenv(OPENAI_API_KEY): print(请先设置 OPENAI_API_KEY 环境变量) exit(1) result run_agent(现在北京时间是几点) print(f最终回答: {result})运行方式export OPENAI_API_KEYsk-xxxx python agent.py你可以看到终端先打印模型决定调用的工具和参数然后打印最终回答。这个过程中的关键点是模型本身不知道时间它依赖工具提供事实。模型按 JSON Schema 格式输出工具调用指令而不是直接写代码。Agent 框架的职责就是连接“模型的意图”和“实际的函数执行”。这段代码虽然简单但已经覆盖了 Agent 的全部核心机制。理解它之后再看 LangChain、LlamaIndex、AutoGen 这些框架你会发现它们做的事情本质上一样只是增强了循环控制、记忆、多工具调度和并发能力。5. 从单工具到多工具Function Calling 与工具设计当 Agent 的工具从 1 个增加到 5 个、10 个甚至更多问题就会从“能不能调用”变成“能不能准确调用”。Function Calling 的设计质量直接决定了 Agent 的成功率。这里有一个容易被忽视的关键模型是根据工具的描述来决定调用哪个工具的而不是根据函数名。因此工具描述写得清不清楚直接影响模型的选择准确率。我们看一个反例和正例的对比反例{ name: get_data, description: 获取数据, parameters: { type: object, properties: { q: {type: string} } } }正例{ name: search_flight_availability, description: 根据出发地、目的地和日期查询航班是否有余票用于机票预订流程。当用户询问某天某航线是否有票时调用。, parameters: { type: object, properties: { origin: {type: string, description: 出发城市三字码如 PEK}, destination: {type: string, description: 目的城市三字码如 SHA}, date: {type: string, description: 出发日期格式 YYYY-MM-DD} }, required: [origin, destination, date] } }后面这种描述模型一眼就能判断“什么时候该用、参数怎么填”工具调用的准确率会明显提升。在多工具场景下我建议为每个工具附加以下元信息名称使用动词开头的英文如search_*、create_*、send_*。描述写清工具的用途、使用场景、以及关键参数的限制。参数明确的类型、格式、必填项尽量枚举可选项。返回格式在描述里注明返回的是列表还是对象以及关键字段含义。如果一个场景里工具数量超过 20 个光靠 Function Calling 可能就不够用了。这时需要考虑把工具分组或者引入 MCP Server 按需加载工具而不是把所有工具都塞给模型。工具越多模型的选择延迟越高出错率也越高上下文消耗同样会急剧增加。另一个现实问题是工具执行会失败。网络超时、参数非法、上游服务返回异常这些都是常态。Agent 的主循环必须对工具失败有明确的处理策略重试、降级、或者如实告诉用户“这个操作失败了建议换一种方式”。否则 Agent 很容易陷入反复调用同一个失败工具的循环里。下面是一个简单的带重试的工具执行封装import time from functools import wraps def retry_on_failure(max_retries: int 2, delay: float 0.5): 工具调用重试装饰器应对临时的上游服务波动。 def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries 1): try: return func(*args, **kwargs) except Exception as e: if attempt max_retries: return {error: f工具执行失败: {str(e)}} time.sleep(delay) return None return wrapper return decorator retry_on_failure(max_retries2) def call_payment_service(order_id: str) - dict: # 这里是真实的支付接口调用 pass这段代码的逻辑是工具执行遇到异常时先重试重试仍然失败则返回一个标准的错误结果。注意Agent 拿到错误结果后应对策略应该是“换一种实现路径”或“请用户确认”而不是机械地再次调用同一个工具。6. 多 Agent 协作架构模式与代码示例当任务复杂度继续上升单 Agent 已经难以胜任时很多人会自然地想到“多 Agent 协作”。但多 Agent 不是银弹。多个 Agent 之间如果不加设计它们不是协作而是互相干扰。你给用户看到的可能是Agent A 生成了任务Agent B 推翻了重来Agent C 在等 A 和 B 的结果最后任务在无休止的对话中死循环。目前业界比较常用的多 Agent 协作模式有三种模式工作原理适合场景风险流水线模式Agent 按固定顺序传递任务结果流程清晰的串联任务如“生成→审核→发布”上游出错会传导到下游编排者模式一个主 Agent 负责规划多个子 Agent 执行任务可拆分成并行子任务的场景主 Agent 可能成为瓶颈协商模式多个 Agent 各自负责一个角色通过对话达成一致需要多方视角的任务如代码 review对话可能无限循环需要强约束在实际工程中编排者模式最常用也最容易控制。主 Agent 负责理解用户目标、拆解任务、分发任务给子 Agent、汇总结果。子 Agent 只负责某一类专精任务。来看一个简化版的多 Agent 编排示例。这里我们不引入重量级框架用 Python 的事件循环加上两个角色 Agent 来演示# 文件路径multi_agent/orchestrator.py 简化版多 Agent 编排器原型。 演示架构 - orchestrator_agent负责拆解任务、分发任务、汇总结果 - researcher_agent负责资料调研类任务 - writer_agent负责内容创作类任务 from dataclasses import dataclass, field dataclass class Task: Agent 任务单元。 task_id: str agent_role: str instruction: str status: str pending result: str dataclass class Orchestrator: 极简编排器演示任务分发与汇总。 agents: dict field(default_factorydict) def register_agent(self, role: str, agent_func): self.agents[role] agent_func def run(self, user_goal: str) - str: # 第一步主 Agent 拆解任务 plans self._plan(user_goal) print(f主 Agent 拆解出 {len(plans)} 个子任务) # 第二步分发任务并收集结果 results {} for task in plans: agent_func self.agents.get(task.agent_role) if not agent_func: continue print(f分发任务 {task.task_id} 给 {task.agent_role}) task.result agent_func(task.instruction) results[task.task_id] task.result # 第三步主 Agent 汇总结果 final_answer self._aggregate(results) return final_answer def _plan(self, user_goal: str): # 实际项目中使用大模型生成任务拆解 # 这里为了演示硬编码两个任务 return [ Task(task_id1, agent_roleresearcher, instructionf调研{user_goal}), Task(task_id2, agent_rolewriter, instructionf写作{user_goal}), ] def _aggregate(self, results: dict) - str: return f综合调研结果和创作草稿最终输出为\n{results} # 子 Agent 的具体实现这里用函数模拟 def researcher_agent(instruction: str) - str: return f[调研结果] 针对『{instruction}』找到 3 个关键事实。 def writer_agent(instruction: str) - str: return f[创作草稿] 基于『{instruction}』生成了 500 字初稿。 if __name__ __main__: orchestrator Orchestrator() orchestrator.register_agent(researcher, researcher_agent) orchestrator.register_agent(writer, writer_agent) final orchestrator.run(写一篇关于 AI 安全的小型报告) print(final)运行上述代码会看到完整的“拆解—分发—汇总”流程。这个示例中任务拆解是硬编码的真实项目中需要用大模型来动态规划任务序列同时要限制子任务的个数避免拆出过多任务导致执行超时。多 Agent 系统在工程上需要额外考虑几个问题任务状态管理每个 Agent 执行到什么状态失败后是否重试需要一个可见的状态机。上下文隔离子 Agent 不应该看到无关的上下文否则会产生幻觉和干扰。结果校验子 Agent 的输出未必可信需要增加一个校验步骤或者由主 Agent 做二次确认。成本控制多个 Agent 意味着多次模型调用成本可能呈指数上升必须在编排层面设定预算上限。7. Agent 开发常见问题与排查方法把 Agent 从小 Demo 推进到真实项目的过程中你几乎一定会遇到下面几类问题。这里整理了一个排查清单建议收藏备用。问题现象可能原因排查方式解决方案模型没有调用工具直接返回文本工具描述不清晰或用户问题确实不需要工具打印模型返回的原始消息确认是否包含 tool_calls 字段优化工具描述在 system prompt 中明确“当 XX 时必须调用工具”工具参数格式错误JSON Schema 定义与实际模型输出不一致检查模型返回的 arguments 是否可被 json.loads 解析在工具描述中说明参数格式和取值范围必要时在代码中做参数清洗工具调用后循环不停止缺少终止条件检查 Agent 主循环是否限制了最大轮数增加 max_iterations 限制达到上限后强制返回结果回答与工具结果不一致提示词没有要求模型基于工具结果作答检查 system prompt 的指令表述明确“你必须基于工具返回的事实回答问题不要编造”多次调用同一失败工具缺少失败状态记忆Agent 没有从错误中学习查看日志中是否记录了历史工具错误将失败原因写入上下文让模型在下一轮避免使用同一策略长任务执行中上下文溢出没有做上下文裁剪或记忆压缩查看 token 消耗日志引入摘要机制将历史对话压缩为摘要后再继续执行多 Agent 互相产生冲突结果子 Agent 职责边界模糊检查每个子 Agent 的 system prompt 是否足够独立明确每个子 Agent 的输入输出格式和职权范围模型调用成本失控循环次数过多或上下文不断膨胀监控每次请求的 token 数设置单任务成本上限超过后自动熔断排查 Agent 问题有一个基本原则先把 Agent 退化成普通对话调用如果没问题再逐步加工具、加循环、加记忆。很多人一上来就怀疑是模型笨其实大多数问题出在自己的工具定义和流程控制上。另外强烈建议在开发阶段开启所有可能的结构化日志输出至少记录每次模型请求的 token 数、模型返回的 tool_calls 内容、工具执行耗时和结果、每一轮循环的输入输出摘要。没有日志Agent 就是一只黑盒出了问题根本无从下手。8. 从 AGNTCon 看 Agent 工程化的几个关键词回到 AGNTCon 阿姆斯特丹九月的这场会议。虽然我们无法在会议开始前看到全部细节但从 Agent 技术的发展阶段来看这场会议的议题大概率会围绕下面这几个方向展开这些方向也正是开发者应该重点关注的。第一个关键词是“可观测性”。Agent 与普通 API 服务最大的不同在于它的行为路径是不确定的。同一个用户请求今天执行了 3 步明天可能执行了 7 步。这种不确定性要求我们把 Agent 运行过程当作分布式系统来观测而不是当作黑盒来看待。主流的方案是通过 OpenTelemetry 链路追踪把每一次模型调用、工具执行、决策点都记录成 Span。你如果要在项目中落地 Agent第一步就应该搭建这样的可观测体系而不是等到上线后再补。第二个关键词是“评测”。传统 NER 任务有准确率、召回率RAG 有召回精度Agent 怎么评目前行业还没有统一的标准。实际项目中比较可行的做法是准备一组典型任务集每个任务定义预期结果和关键检查点通过 Agent 完成任务的通过率、平均耗时、平均成本、失败原因分布来评估系统质量。评测要尽量自动化和回归化每修改一次 prompt 或工具定义就要重跑一遍。第三个关键词是“安全”。Agent 能够自主调用工具这意味着权限风险比普通应用更高。如果 Agent 能读写数据库、能发邮件、能支付那么一旦 prompt 被注入恶意指令后果可能很严重。工程上必须做到最小权限原则Agent 默认没有任何权限每项工具调用需要独立的权限校验敏感操作需要用户人工确认所有操作留下审计日志。第四个关键词是“成本治理”。Agent 的价值在于替代人工完成多步骤任务但每一次工具调用都意味着一次模型请求。一个任务如果涉及 10 次模型调用成本可能是一句对话的 10 倍。合理的做法是为 Agent 任务设置预算上限轻量任务用便宜的模型复杂任务才升级到更强模型优先使用缓存和本地小模型处理边缘任务。这些关键词其实反映了同一件事Agent 正在从一个 demo 概念变成一个需要严肃对待的软件工程领域。会议上的分享也许不会告诉你某个框架的具体用法但这些工程问题和行业共识才是真正值得带回家的东西。9. Agent 开发最佳实践与工程建议结合前面的内容这里总结一份可以直接用于实际团队的 Agent 工程实践清单。9.1 架构选择Workflow 优先Agent 兜底在动手开发前先问自己这个业务真的需要 Agent 吗如果业务路径明确、步骤固定就用 Workflow只有在需要动态决策、分支复杂、路径无法预判时才引入 Agent。用 Agent 解决 Workflow 的问题只会增加不可控性和成本。9.2 工具设计宁可少而精不要多而杂把 Agent 的回归测试准确率作为一个硬指标来维护。每次修改工具定义、提示词或模型版本都重跑一遍测试集确认核心任务的完成率没有下降。没有自动化评测的 Agent 系统在持续迭代中一定会退化只是时间问题。9.3 提示词管理纳入版本控制System prompt 和工具描述按代码一样管理纳入 Git带上版本号。每次修改要记录原因。生产环境要支持 prompt 的灰度发布和快速回滚。很多 Agent 线上事故最后排查下来就是 prompt 被手动改了一下。9.4 安全边界最小权限和人工确认Agent 能接触的数据和工具要在设计阶段就划清边界。数据库操作默认只读涉及变更、删除、资金和私域内容的操作必须经过人工审批或二次确认。对外暴露的 Agent 服务必须做输入过滤和注入检测。9.5 可观测性从第一天就开始在开发第一个 Agent 时就接入结构化日志和链路追踪记录每一轮“模型—工具—结果”。不要等到生产环境出了问题再补。Agent 的调试成本远高于传统接口日志越完整排错越快。9.6 成本控制预算上限和模型分级为每个 Agent 任务设定 token 预算和成本上限达到上限后停止并提示用户。在同一套 Agent 系统中根据任务难度选择不同规模的模型简单任务不要用大模型复杂任务不要用小模型硬撑。9.7 采用开源框架时注意抽象边界像 LangChain、LlamaIndex 这些框架能帮你快速搭建原型但也可能让你忽略底层机制。推荐的做法是先用最小代码自己实现一遍核心循环再使用框架进行规模化和工程化改造。这样你对框架的理解深度会完全不一样遇到问题时也能快速定位是框架 bug 还是自己的逻辑错误。10. 总结与后续学习建议AGNTCon 选择在阿姆斯特丹举办九月场次本身就是一个值得注意的信号Agent 不再是硅谷极客圈的小众话题而是一个全球开发者都在参与的技术浪潮。会议的价值在于把散布在各处的 Agent 工程经验集中展示出来尤其是那些“Demo 跑得通、生产上不去”的问题非常需要现场讨论和碰撞。对于开发者来说我建议的学习路径是先自己动手实现一个最小 Agent理解“模型—工具—循环”的核心机制。把工具数量扩展到 5 到 10 个体会工具描述、参数校验和失败重试的工程细节。尝试做一个多 Agent 编排原型理解任务拆解和结果汇总的复杂度。再回到框架层用 LangChain、LlamaIndex 或 AutoGen 等工具提升开发效率。最后搭建一个完整评测集用数据驱动的方式持续优化 Agent 质量。Agent 开发的真正门槛不在于能不能调通一个 API而在于你能否用工程化思维管理一套自主决策系统。这个过程中会踩很多坑但每一个坑都会让你对模型能力、系统设计和业务边界有更深的理解。如果你正准备在项目中落地 Agent希望这篇文章的代码示例、排查清单和工程实践能给你一个可靠的起点。后续我也会继续关注 AGNTCon 相关的议程和技术分享有新的工程内容和公开资料时再和大家一起拆解。