最近在重新梳理一个问题：

如果本身已经做过软件开发，现在想转 Agent 应用开发，到底需要学什么？

网上常见的关键词很多：

LangChain、LangGraph、RAG、Memory、MCP、Multi-Agent、Context Engineering、Eval、Sandbox……

如果一个个拆开看，很容易觉得这条路线特别散。

所以这次换个方式。

先看企业真实岗位需要什么，再把这些技能放回一个完整的 Agent 系统里，最后再去 GitHub 里找对应的成熟项目。

整条链路大概是：

岗位 JD ↓抽取技能 ↓重新整理成 Agent 工程框架 ↓用 GitHub 项目验证 ↓反推软件开发转 Agent 的学习路线

先把最终整理出来的框架放在前面。

01｜Agent 应用开发的完整框架

目前比较适合的软件工程视角，大概可以整理成这样：

┌────────────────────────────────┐│       Agent Application        ││      Web / App / CLI / API     │├────────────────────────────────┤│        Orchestration           ││ Workflow / Multi-Agent / HITL  │├────────────────────────────────┤│         Agent Runtime          ││ Loop / State / Planning        ││ Retry / Checkpoint / Recovery  │├────────────────────────────────┤│           Context              ││ Prompt / History / RAG         ││ Memory / State / Tool Results  │├───────────────┬────────────────┤│     Model     │     Action     ││ LLM/Reasoning │ Tools / MCP    │├───────────────┴────────────────┤│       Software Infra           ││ DB / Redis / MQ / Docker       ││ Auth / Storage / Distributed   │├────────────────────────────────┤│     Production & Quality       ││ Eval / Trace / Security        ││ Cost / Latency / Monitoring    │└────────────────────────────────┘

如果只看关键词，Agent 开发像是几十项独立技能。

放到这张图里以后就会清楚很多：

Software Engineering        ↓Model        ↓Context        ↓Agent Runtime        ↓Tool / MCP        ↓Workflow / Multi-Agent        ↓Eval / Trace / Production

这些东西共同组成了一套完整的 Agent 应用工程体系。

接下来再看 JD，就会更容易理解企业为什么会同时要求这些能力。

02｜先看 JD：企业到底在招什么人？

先看一个比较典型的岗位。

百度目前公开的 Agent 应用全栈岗位，已经明确出现：

• Planning
• Acting
• Reflection
• Tool / API
• Memory
• Reasoning & State
• Multi-Agent
• RAG
• Eval

这一套要求基本覆盖了 Agent 从规划、行动、状态管理到评测的完整闭环。

京东的部分 Agent 岗位更加偏工程化，已经直接出现：

• Model Gateway
• Agent Runtime
• Context 状态管理
• Tool / Plugin Registry
• Streaming
• Semantic Cache
• Prompt 管理
• Eval
• Trace / Replay

同时依然要求：

• Java / Python / Go
• 微服务
• 数据库
• Redis
• MQ
• 分布式系统
• 高并发
• 容器化

再把百度、京东、阿里、腾讯、美团这一类岗位放到一起，会看到一个比较明显的趋势：

Agent 应用开发和传统软件工程之间有很强的连续性。

企业需要的能力，可以简单理解成：

传统软件工程+LLM 应用能力+Agent Runtime+Context / Tool / Workflow+Eval / Production

软件开发原本积累的 API、数据库、缓存、异步任务、分布式系统、容器、日志、监控等能力，依然会直接参与 Agent 系统的构建。

新增的部分，主要集中在模型周围。

03｜这些 JD 关键词，其实都挂在同一条执行链路上

把 JD 里的词全部摊开，大概是：

Python / Java / GoPromptRAGEmbeddingMemoryContextTool CallingFunction CallingPlanningReflectionStateWorkflowMulti-AgentMCPSandboxAgent RuntimeEvalTracingRedisMQDockerK8s……

如果顺着一个 Agent 的实际运行过程去看，它们会变成一条很清楚的链路：

User ↓Application ↓Agent Runtime ↓构建 Context ↓LLM 决策 ↓Action / Tool Call ↓执行 Tool ↓Observation ↓更新 State ↓重新构建 Context ↓继续调用 LLM ↓…… ↓任务完成

最小的逻辑甚至可以压缩成：

while not done:    context = build_context(state)    action = llm(context)    observation = execute(action)    state.update(observation)

整个 Agent 系统的大量工程能力，基本都是围绕这个循环逐渐长出来的。

04｜LLM 在 Agent 里承担的是决策角色

传统 LLM 应用大概是：

用户 ↓Prompt ↓LLM ↓Answer

Agent 场景里，模型需要持续判断：

现在要不要搜索？应该读哪个文件？要不要查询数据库？应该运行什么命令？当前信息够不够？任务是否已经完成？

于是模型开始承担更多决策职责。

传统程序里，流程通常提前写好：

if condition:    function_a()else:    function_b()

Agent 里，一部分流程会变成：

Context ↓LLM ↓Tool ATool BContinueFinish

下一步行为由模型根据当前上下文动态选择。

这也是 Agent 系统和传统应用最明显的区别之一。

05｜Prompt 会逐渐进入更大的 Context 体系

模型每次真正做决策时，看到的内容可能包括：

System Instructions当前用户任务Conversation History当前 State历史 Tool ResultsRAG 检索结果Long-term Memory文件内容可用 Tools任务执行进度

把它们放在一起看：

Prompt ─────────┐Conversation ───┤RAG ────────────┤Memory ─────────┼──→ Context → LLMState ──────────┤Tool Result ────┘

Prompt 只是 Context 中的一部分。

RAG 主要负责提供当前需要的外部知识。

Memory 负责提供过去积累的信息。

State 记录当前任务执行到哪一步。

Tool Result 则把刚刚发生的执行结果重新送回模型。

所以 Agent 场景下，一个很核心的问题会变成：

这一轮模型应该看到哪些信息？

这也是 Context Engineering 越来越重要的原因。

06｜Tool 让模型真正具备执行能力

Agent 常见的 Tool 包括：

search()read_file()write_file()run_shell()query_database()browser()send_email()create_issue()

执行链路会变成：

LLM ↓Tool Call ↓真实执行 ↓Observation ↓LLM

从这一刻开始，模型已经能够直接影响外部系统。

比如：

执行 Shell修改文件操作浏览器访问数据库调用内部 API

于是工程里会自然出现新的约束层：

• Permission
• Sandbox
• Human-in-the-loop
• Security
• Guardrail

Agent 能力越强，这些限制和保护机制越重要。

07｜Agent Runtime 是整个系统的核心层

已经有了：

LLMContextMemoryRAGTools

接下来还需要解决大量运行时问题：

Agent 从哪里开始？什么时候结束？最多执行多少步？Tool 调用失败怎么办？模型超时怎么办？State 存在哪里？任务跑到一半服务挂了怎么办？怎么恢复？什么时候需要用户确认？如何暂停？如何 Streaming？怎么限制 Token？怎么限制权限？

这些能力会逐渐汇聚到：

Agent Runtime

可以大致理解成：

              Agent Runtime      ┌─────────────────────┐      │                     │Input → State → Context → LLM      ↑                │      │                ↓      │              Action      │                ↓      │               Tool      │                ↓      └── Observation ─┘      Retry      Timeout      Checkpoint      Permission      Streaming      Recovery      Stop Condition

所以现在越来越多新的 JD 里，已经直接出现：

Agent RuntimeContext StateTool RegistryEvalReplay

这说明 Agent 应用正在逐渐形成独立的 Runtime Engineering 层。

08｜Workflow 和 Multi-Agent 属于更上层的编排

Runtime 主要解决单个 Agent 如何持续运行。

Orchestration 解决整个系统的流程组织。

例如：

START ↓Planner ↓Search Agent ↓Analyze ↓信息够吗？ ├─ NO → Search │ └─ YES      ↓    Writer      ↓ Human Review      ↓     END

这一层会涉及：

• Workflow
• State Machine
• DAG
• Checkpoint
• Human-in-the-loop
• Multi-Agent
• Durable Execution

LangGraph 这一类框架，主要解决的就是这一层。

它帮助开发者管理：

StateNodeEdgeCheckpointPersistenceResumeHITL

所以理解一个框架时，最好先问：

它在整个 Agent 系统里负责哪一层？

这样会比直接记 API 清楚很多。

09｜Eval 决定 Agent 能不能进入生产环境

传统程序里，经常可以比较明确地判断输入和输出。

Agent 的执行过程可能很长：

Input ↓LLM ↓Search ↓Read ↓Search Again ↓Call Tool ↓Think ↓Write ↓Result

这时候需要关注的指标也会变多：

任务最终完成了吗？Tool 调用是否正确？为什么搜索了 15 次？为什么消耗了这么多 Token？从哪一步开始跑偏？Prompt 修改后成功率有没有提升？更换模型以后整体效果如何？

所以生产级 Agent 系统会越来越强调：

• Eval
• Tracing
• Replay
• Observability
• Cost
• Latency
• Regression Test

一个 Agent 能够跑通，只能说明基本链路成立。

能够被观察、评测、恢复、优化，才更接近真正的生产系统。

10｜GitHub 上有哪些项目值得拆？

有了前面的框架，再去看 GitHub 项目就容易很多。

可以分别从不同层理解 Agent Engineering。

1. OpenHands

适合研究：一个 Agent 到底怎么真正执行任务。

GitHub：

https://github.com/OpenHands/OpenHands

重点可以看：

Agent LoopContextToolStateRuntimeSandboxPermissionPersistenceTracingEval

它的大致执行链路可以理解成：

History ↓Context ↓LLM ↓Action ↓Tool ↓Sandbox ↓Observation ↓History

如果软件开发转 Agent 只准备深入拆一个项目，我会优先看 OpenHands。

因为它能把很多抽象概念直接落到真实源码里。

2. LangGraph

适合研究：有状态 Agent 系统怎么编排。

GitHub：

https://github.com/langchain-ai/langgraph

重点看：

StateNodeEdgeWorkflowCheckpointPersistenceHITLDurable Execution

它特别适合理解复杂 Agent 系统里的状态管理和执行恢复。

3. AgentScope

适合研究：一个完整 Agent Framework 有哪些能力。

GitHub：

https://github.com/agentscope-ai/agentscope

目前覆盖的能力很多：

ReActToolsSkillsMemoryPlanningMCPRAGHuman-in-the-loopEvaluationMulti-AgentSandbox

如果想横向看一个 Agent Framework 最后会长成什么样，AgentScope 很适合。

4. Dify

适合研究：Agent 怎么进入真实产品和平台。

GitHub：

https://github.com/langgenius/dify

重点可以看：

WorkflowModel ManagementRAG PipelineAgentToolsMCPObservabilityAPIMulti-Tenant

Dify 更适合看 Agent 产品化以后，需要补齐哪些平台能力。

11｜如果重新设计学习路线

结合 JD 和这些项目，我会把学习路线排成四个阶段。

第一阶段：自己手写最小 Agent

先真正搞懂：

LLM ↓Context ↓Tool Call ↓Observation ↓State ↓LLM

把 Agent Loop 跑通。

第二阶段：拆 OpenHands

重点理解：

Agent LoopToolContextRuntimeSandboxSecurityState

看看这些概念在真实项目里怎么实现。

第三阶段：学 LangGraph

理解：

WorkflowStateGraphCheckpointPersistenceHuman-in-the-loopDurable Execution

补齐复杂 Agent 系统的编排能力。

第四阶段：看 AgentScope 和 Dify

继续补：

MemoryRAGMCPSkillsMulti-AgentEvalObservabilityServicePlatform

到了这里再去学具体框架 API，理解成本会低很多。

因为你已经知道：

这个模块在整个 Agent 系统里到底负责什么。

12｜软件开发转 Agent，需要补的东西其实很明确

原来的软件工程能力：

APIDatabaseRedisMQConcurrencyDistributed SystemDockerAuthLoggingObservabilitySystem Design

依然全部有价值。

Agent 场景主要新增的是：

ModelContextMemoryToolAgent LoopRuntimeWorkflowMCPEval

可以把整个变化理解成：

在原来的软件工程系统里，引入了一个会自己做决策、会调用工具、行为带有一定不确定性的执行单元。

传统软件工程长期研究的是：

如何让程序逻辑稳定执行。

Agent Engineering 进一步需要解决：

如何让带有不确定性的智能能力，在一个确定的软件系统中稳定工作。

模型负责提供智能。

Runtime、Context、Workflow、Sandbox、Eval、Tracing 等工程模块，则负责管理这种智能的运行过程。

把这些关系理顺以后，Agent 应用开发就没有一开始看起来那么散了。

它本质上依然是一套软件工程。

只是软件系统里，多了一个新的执行者。