最近实习接手了一个 Agent 项目，不过我之前从来没接触过实际的 Agent 应用开发（完全小白），所以萌生了学一些相关知识的念头，打算写一点文章记录和沉淀下来。
在制造某个工具前，我们必须先说清楚这个工具能解决的问题是什么。我认为目前 Agent 解决的是「在允许非幂等操作的某些场景下，能接受有一定偏差的、可预测的返回结果」的复杂问题，例如最常见的编码任务，我们只需要任务的完成，不需要太关注编码的具体实现；又例如日报，我们允许 Agent 返回一个它决策和加工出来的日报，只要这个结果达到人所给出的某个预期或者标准即可。
仔细想想，这实际上就是老板-员工的模式，老板说你今天得给我一个完整的 xxx 方案，员工就去自主规划-调用工具（可能是 agent）-完成任务-返回结果。这个方案就是一个可以有一定偏差的、但是（可能）处于预期范围内的结果。
Agent 并未拥有一个业界内的统一定义，不过大部分机构认为 Agent 是一个「能够独立行动、使用工具、规划并执行复杂任务的系统」。
以各类 LLM 作为基底，目前市面上有这么几种常见的系统：
-
augmented LLM
通常是单次模型调用，但是并非裸 LLM 调用，而是有一定的封装，例如我们使用的 ChatGPT 网页、DeepSeek 网页、豆包，它们的工作流程都是「用户发起一次问题，LLM 回答一次问题」，它们带有记忆、工具、检索上的增强，以及一些输入检测等等。
-
workflow
常见的如 Dify、Coze、n8n，都属于这类范畴，我们使用代码去预定义路径，从而确定任务更稳定、更可控。例如日报，我们可以拆分为这么几步：收集信息-加工信息-返回信息，每个步骤又能写出一些更小的精确步骤，这种时候，采用 workflow 就很不错。
-
agent
workflow 是通过代码编排 LLM 和工具的系统，而 agent 则是由 LLM 动态引导工具使用和自身流程。面对 1. 步骤数不确定 2. 可能需要动态选择工具 3. 中途根据观察结果改变计划这种开放式任务，agent 则更灵活。例如最常见的编码任务，我们想要一个 todolist，在这里做编排是成本大于收益的（除了复杂架构任务）。
如果结合 Anthropic 的 Building Effective Agents ↗ 来看，上面这三类还可以再拆得更细一点。Anthropic 的一个核心观点是：不要一上来就做“全自动 Agent”，而是先从最简单、最便宜、最可控的方案开始，只有当单次调用不够用时，才逐步增加复杂度。
再把“模式”讲白一点#
简单来说，Anthropic 那篇文章其实是在提醒大家：很多问题并不需要一上来就上一个“全自动 Agent”。很多时候，一个带检索或工具的大模型、一个固定的 workflow，甚至只是把任务拆成几步串起来，就已经够用了。只有当任务本身足够开放、步骤不确定、需要中途根据反馈不断调整路线时，Agent 的价值才真正开始体现出来。
如果再结合 Lilian Weng 的 LLM Powered Autonomous Agents ↗ 来看，Agent 的核心无非也就是几件事：先理解目标、再做规划、过程中调用外部工具、必要时保留记忆，并根据执行结果不断调整下一步。换句话说，Agent 并不是某个突然冒出来的新物种，而是把“大模型 + 工具 + 记忆 + 反馈循环”更系统地拼在一起。
然后我们回到目前国内就业市场里的职位 JD，拿两个例子，看看 agent 开发到底要干嘛：
某节：
- 本科及以上学历，计算机及相关专业；
- 熟悉至少一门编程语言，包括但不仅限于 Java/Objective-C/C/C++/Python/Go/JS 等；
- 熟悉 AI Agent 相关技术，了解工具开发、Agent 流程设计、评估系统、上下文工程等体系；了解主流 AI 模型及其应用场景，有从 0-1 搭建 AI Agent 应用经验者优先，能够独立完成 Agent 应用的设计、开发和部署工作；
- 熟悉一般性架构设计思想，包括不限于服务化、异步、高可用、可扩展等；良好的服务可靠性意识，包括不限于监控、容灾等；
- 良好的业务理解抽象和问题解决能力，优秀的团队协作能力；
- 研发效能相关方向研发经验者优先。
某鹅：
- 负责 AI Agent 工作流的设计与研发，落地生图、生视频等业务场景的端到端自动化流程；
- 基于 LLM（GPT/Claude/DeepSeek/混元等）构建 Agent 的任务规划、工具调用、记忆管理、多轮决策能力；
- 使用 Go/Python 构建高并发 Agent 服务框架与调度系统（任务编排、工作流引擎、队列消费、稳定性治理）；
- 对接算法，完成生图/生视频模型的能力对接、Prompt 工程与效果调优；
- 设计并实现 Agent 编排框架（Workflow/DAG/多 Agent 协作），支持复杂创作链路（脚本→分镜→生图→生视频→剪辑合成）；
- 持续优化 Function Calling、Tool Use、RAG 检索、上下文管理等核心模块，提升 Agent 稳定性与生成质量；
- 配合产品/算法团队完成效果评估、badcase 分析与迭代。
这些 JD 看起来很唬人，但如果翻译成人话，其实就是：你不只是要“会调模型”，你还得会把模型放进一个真实系统里，让它能拿到信息、调用工具、在失败时重试、在关键节点让人接管，并且最终对业务结果负责。
之前在L站和一个佬友讨论了一下，他回复「在业务场景下，其实可以理解为原来必须用规则进行内容清洗、利用规则去硬套模版生成的活交给llm了，这样对于开发者而言，只用维护简单的数据获取，在业务场景下可以仔细研磨output以达到给用户返回的内容最优，这个才是agent最大的优势」
Agent 的未来#
我觉得 Agent 的未来大概不会是“一个万能数字员工立刻接管所有工作”，而更像是一种逐步嵌进真实业务流程的能力。它会先在那些目标明确、反馈清晰、结果相对容易验证的场景里落地，比如编码、检索分析、客服、报表处理，然后再慢慢往更复杂的链路里渗透。
真正决定 Agent 能不能跑起来的，可能也不会只是模型本身有多强，而是工具接口设计得好不好、记忆系统稳不稳定、权限边界清不清楚、失败之后有没有兜底。换句话说，未来的重点不只是“让模型更聪明”，而是“让模型在现实系统里更可靠地做事”。
所以如果让我现在用一句话总结：Agent 的未来不是单纯追求更强的自主性，而是在可控前提下，把模型的行动能力真正接到现实系统里。
总结一下，就是将 Agent 落地到业务某一环中，并做好 Agent 的定制化和工程化，确保该 Agent 能稳定完成业务目标。