前言
到了 2026 年，随着模型能力越过某个门槛，Agent 产品设计已经不像一年前那样高度依赖基础模型迭代，模型输出也开始达到相对稳定的工程可用状态。
Agent 工程师的重心越来越多地从“技术探索”转向“应用落地”。对大多数企业团队来说，问题已经很具体：
从 0 开始做一个 Agent，到底是什么流程，到底应该怎么把它做成能上线、能复用、能评估、能被业务长期使用的产品？
过去两年，从 Prompt Engineering、Context Engineering 走到 Harness Engineering，Agent 工程领域蓬勃发展，工程师们也该从各种技术宏大叙事里走出来了。
Agent 只是实现业务目标的一种方式，别把它当成产品目标。
企业级 Agent 的落地，核心是把不确定性一点点收敛，模型顶级能力只是其中一部分。
结合我近一年多开发 Agent 应用的实践，这篇文章我想总结下从 0 开始开发一个 Agent 应用的基本流程和经验实践（只是个人思考，Agent 应用开发目前并无最佳实践）。
阅读大纲
- Agent 应用，你到底要交付什么？
- 全通用型 Agent？一个答案求解所有问题的美丽幻想
- AI 新交互，AI 应用===聊天框？
- 从对话提炼任务，让 Agent 执行逻辑可观测、可留存、可复用
- Agent 框架非彼框架
- Agent 万能药水？从 MCP 到 Skill
- 知识库：RAG？LLM Wiki？Graphify？
- 接入 Git 仓库：成本很高，但价值很大
- Agent 到底如何做测试？是否要写测试集？
- 为什么企业级 Agent 这么难落地？传统技术团队面临挑战
- 总结
1. Agent 应用，你到底要交付什么？
先搞清楚：你最终到底要交付什么？
如果你的目标只是“实现某个 AI 技术”，比如做一个 RAG、写一个 Skill、接一个 MCP、跑通一套多 Agent 调度、设计一套 plan，那当然也有价值。但这只是技术验证，得到的是一些中间态产物，或者 demo 级的演示结果。
它最多证明“这条技术链路能跑”，不能证明“这个东西能被业务长期使用”。
- 知识库：解决信息来源；
- Skill：解决高频能力复用；
- MCP：解决外部工具和上下文接入；
- 工程代码：解决流程、状态、权限、观测和稳定性；
- AI 技术：解决模糊输入、语义理解、内容生成和推理判断。
这些都重要，但最终交付物依然要落到产品上。
真正的出发点应该是：面向什么业务，交付什么产品，过程里使用什么技术。
业务定义问题，产品定义体验和边界，工程代码保证系统稳定运行，AI 技术负责处理传统程序难以穷举的那部分不确定性。 总之，AI 是技术的一部分，技术是产品实现的一种工具，产品才是业务价值的承载。
2. 全通用型 Agent？一个答案求解所有问题的美丽幻想
面对 AI 展现出来的能力，很多人都会天然兴奋。它确实有巨大的潜力，也给了我们足够大的想象空间。但问题也在这里：越是不确定，越容易让人浮躁。
于是很容易出现一个念头：能不能用一个答案求解所有问题？
只要做一个足够复杂、足够聪明的 Agent，就能覆盖掉现有产研体系里大量琐碎、重复、复杂的问题吗？
从去年开始做 Agent 相关方向时，我们内部其实不止一次讨论过类似问题，尤其是在产研基建领域：
- 能不能把所有产品能力都提炼成 MCP，交给一个超级 Agent 来统一调度？
- 能不能把所有零散文档都整理进知识库，得到一套通用知识问答能力？
- 能不能持续产出大量高质量 Skill，最后拼出一个全面的 Agent 应用？
- 能不能用一个复杂 Agent 覆盖创建项目、代码检索、构建部署、问题排查、流程审批这些基础技术问题？
我的判断是：不能。
Agent 能解决传统工程里的一部分问题，但它解决不了所有底层复杂度。核心原因很简单：你的 Agent 能力仍然建立在旧的基础设施之上。比如：
- 创建项目依赖 GitLab；
- 构建部署依赖部署平台；
- 知识问答依赖文档质量和更新机制；
- 流程自动化依赖审批、权限、状态和审计系统。
而目前大多数底层能力，都是围绕传统软件系统建立的。它们主要服务人的操作习惯，并没有按 AI 调用方式重新设计。
如果不处理这一层，只是在上面套一个 Agent 入口，本质上只是把旧系统的复杂度包装成了一个更高级的入口。
技术最后还是要回到本质：复杂度不会消失，只会转移。
同样的逻辑放到业务流程里也成立。
Agent 不会自动修复一个混乱的流程。如果一个流程原本就靠口头经验、临时判断、隐性规则和个人关系运转，Agent 接进去之后，只会把这种混乱放大。
那如果还想做更通用的 Agent，应该怎么做？
我的经验是，底层能力一定要配合重构。先去思考 Agent 需要什么样的基础能力，再去设计面向 AI 的接口、协议、权限、数据或事件流。面向 AI 的基础能力建设成本，很多时候会低于传统面向人的系统改造成本，这件事未必一定很重。
3. AI 新交互，AI 应用===聊天框？
Chat 对话框似乎已经成了各种 Agent 应用的标配。
这当然有道理。自由开放的对话，确实能发挥模型在自然语言理解、开放式问答和复杂表达上的优势。
但这也是最容易偷懒的设计。
聊天框当然重要，但如果一个产品的所有能力都靠用户用自然语言触发，再让模型去做意图识别，本质上就是把产品设计的责任甩给模型。
我更倾向于把 Agent 的交互入口拆成几层：
- 明确入口：按钮、菜单、卡片、快捷指令，适合高频固定任务。
- 可观测的执行过程：执行过程要输出足够的信息，让用户知道 Agent 正在做什么，执行类 Agent 尤其重要。
- 丰富的基础上下文：提前提供 Git 仓库、知识库、任务详情、文档、日志等基础上下文，减少用户手动粘贴。
- 精心调试的 Skill 和 MCP：把复杂但高频的流程封装成可复用能力，但必须在当前 Agent 中反复调试效果，不能开放式地随便接入。
- 自然语言入口：处理开放问题和无法提前枚举的需求。
能用产品形态明确的意图，就不要再交给模型做意图识别，交互层要尽量丰富。
这样做会让 Agent 更稳定。好的 Agent 交互，应该把能力放到合适的位置，让它自然嵌进原本的工作流里，少让用户在聊天框里反复描述需求。
在我最新的 Agent 交互设计中，我围绕“对话框如何获得更丰富的上下文”重新做了一轮优化：包括快速命中工作流的入口、调试后的 Skill、基础代码仓库、适配的知识库选择、移动端 APP 上下文、执行任务的透明化与重复引用，以及日志的快速接入等能力。
4. 从对话提炼任务，让 Agent 执行逻辑可观测、可留存、可复用
单纯的 Agent 对话很容易用完就散。
用户问了一次，Agent 回答了一次，窗口一关，过程没了，结果也很难复用。这个形态适合临时问答，一旦进入企业级任务，就会明显不够用。
我在新的 Agent 产品中增加了**“任务”**的概念，将对话背后的执行逻辑做任务级别的沉淀。
任务至少应该有几个东西：
- 用户目标；
- 输入上下文；
- 执行步骤；
- 工具调用记录；
- 产出结果；
- 失败原因；
- 可继续执行的状态；
- 可复用的模板；
- 可回溯、可引用的历史上下文。
这样做有几个直接好处。
- 第一，用户看得见 Agent 在干什么。
它现在是在读取 Git 仓库、查询知识库、调用 Skill、生成计划、等待确认，还是正在处理异常，用户都应该能看到。执行类 Agent 尤其需要这种可见性，否则用户很难建立信任。
- 第二，任务可以留存，也可以继续被使用。
企业里的很多工作并非一次性聊天，它们更像可以复用的流程。今天做了一次代码分析，明天还要做；这个项目做了一次知识整理，下个项目还要做。如果每次都从聊天框重新开始，Agent 的价值会被浪费掉。
更重要的是，历史任务可以进入新的上下文。
用户看到之前的某个任务，可以随时引用它继续问答：基于上次代码分析继续排查、把上次任务结果整理成报告、沿用这套流程再跑一次、对比两次执行结果的差异。这样一来，Agent 逐渐摆脱只依赖当前窗口临时拼上下文的状态，开始拥有一套可回溯的工作记录。
- 第三，任务可以变成产品资产。
一次好的 Agent 执行，应该留下的不只是结果，还包括一套可复用路径：哪些输入有用，哪些工具被调用，哪些步骤可以自动化，哪些地方需要人工确认。
聊天负责表达意图，任务承载执行过程，结构化 UI 让状态和记录可见。三者组合起来，才更像一个真正能用的 Agent 产品。
5. Agent 框架非彼框架
“Agent 框架”这个叫法很容易误导人。Agent 就不存在通用性技术框架！！！
传统技术语境里的框架，通常对应一套相对成熟的开发范式。比如 React 定义了一套前端开发方式：组件化、状态驱动、声明式 UI、生态工具链。开发者接受这套范式，就能围绕它组织代码。
Agent 的问题，来源于业务的无限复杂度。想用一套 Agent 框架解决所有架构问题，本质上就是想用一套技术解决所有业务问题，这不可能。所以不要对 Agent 框架抱有太大期待，Agent 设计更重要的是业务场景。
所以我不太相信有什么通用的 Agent 最佳设计模式。像 LangGraph、OpenAI Agents SDK、DeepAgents 这些东西，我更愿意把它们当成实用工具包。它们确实能降低不少 Agent 工程里的代码复杂度。
| 框架 | 场景 | 建议 |
|---|---|---|
| LangGraph | 自己做流程编排、状态流转、人工确认、长任务恢复 | 适合你已经知道流程怎么拆，只需要图结构和状态机制把它跑起来。 |
| DeepAgents | 复杂 Agent、长任务、代码类任务、本地执行任务，需要计划、文件系统、SubAgent、记忆和沙箱 | 适合快速搭一个复杂 Agent Harness，比从零拼基础能力省很多事。 |
| OpenAI Agents SDK | 基于 OpenAI 生态做服务端 Agent，需要 tools、MCP、handoff、guardrail、tracing 和状态管理 | 适合用 code-first 的方式把 Agent 放进自己的产品服务里。 |
| 模型 SDK + 自己的 Harness | 明确的小场景，比如问答、摘要、简单工具调用 | 大多数时候这就够了。不要为了“看起来像 Agent”先把复杂框架接进来。 |
流程编排用 LangGraph，开箱做复杂 Agent 可以看 DeepAgents，OpenAI 生态里的服务端 Agent 用 Agents SDK 会更顺手。简单任务链路直接写工程代码，通常更快、更稳，也更好调。
很多人刚开始做 Agent，会寄希望于框架提供一套好的开发方式。最好选一个足够强的框架，然后按它的范式往里填业务，最后自然得到一个成熟的 Agent 应用。
框架最多帮你少写一部分基础设施代码。业务怎么拆、上下文怎么组织、工具怎么暴露、用户在哪里确认、失败后怎么兜底，这些都要回到具体产品里重新设计。
我的建议很简单：
- 不要为了用框架而用框架，尽量不用框架；
- 不要一上来就深度使用框架，先从最简单的用法开始；
- 框架越复杂，Agent 流程越复杂，体验就越差，调优空间越小，这是必然的。
- 绝大多数 Agent 应用，轻量模型 SDK + 自己的 Harness 就已经完全够用。
这里的 Harness 可以很朴素，一些工程代码 + LLM 调用就能解决多数业务问题。等业务真的复杂到需要图结构、长任务、多节点流转、多 Agent 协作时，再引入 LangGraph、DeepAgents 这些工具也不晚。
框架应该服务业务场景，别让业务去适配框架。
6. Agent 万能药水？从 MCP 到 Skill
大家都在追求释放 LLM 更大价值的解法，Skill 和 MCP 是这两年热度最高的产物。（当然，今年已经没那么多人提 MCP 了。）
MCP 让外部工具和上下文有了更标准的接入方式，Skill 则把高频任务封装成可复用能力。放在个人工具里，比如 Claude Code 或 Codex，用户自己安装几个量身定制的 Skill，确实能明显提升效率。
但 Agent 产品完全是另一个状态。
企业级 Agent 不能开放接入一大堆 Skill，然后指望它自然获得非常广泛、非常稳定的能力。Skill 越多，MCP 越多，上下文越复杂，模型选择、参数传递、权限判断、错误恢复都会变得更难。复杂度上去之后，效果很难线性变好，只会更难预测。
即使 Skill 设计得很好，MCP 接口也很规范，我的建议仍然是：精调。
在 Agent 内部接入时，我认为只有一个思路：
- 少量接入；
- 明确场景；
- 反复调试；
- 控制上下文；
- 观察真实效果；
- 持续收敛边界。
不要指望“开放式接入”解决企业级 Agent 的能力问题。企业级 Agent 更需要一组被精心挑选、反复验证、能稳定服务当前业务场景的能力。那种看起来很丰富、实际调用效果不可控的能力市场，对上线产品意义不大。
7. 知识库：RAG？LLM Wiki？Graphify？
传统 RAG 知识库放到 Agent 上，我觉得是天生不太适配。
RAG 的基本逻辑是：从海量知识里召回一部分内容，塞进模型上下文，让模型基于这些内容回答。听起来很合理，但它有一个底层问题：原始文档通常会先被切成很多 chunk，再做相似度匹配。
算法真正拿来匹配的是切片后的文本。原文里的章节关系、上下文指代、业务前提、版本信息，都被拆散了。
chunk 无论怎么切，语义都会散。一个规则原本依赖上文条件，切出来后只剩一句结论；一个产品说明原本依赖模块背景，检索时只剩局部描述。相似度可能很高，但放进 Agent 上下文后就是错的、缺的、不准确的。
Agent 上下文里混入一个语义残缺的 chunk，风险很大。
Agent 上下文里的知识，更应该被提前整理好：
- 原始文档结构要清楚；
- 业务规则要显性化；
- 关键概念要提前归纳；
- 常用流程要沉淀成稳定材料；
- 不适合进上下文的内容要提前剔除。
换句话说，与其把希望都放在 RAG 算法和召回策略上，不如先优化知识库原文档。无论如何，文档质量都是基础，否则做再多也是屎上雕花。
并且需要警惕：“从海量知识里选一段内容塞进上下文”这种业务场景，是否真实存在。
新一代知识库方案：LLM Wiki 与 Graphify
这两年也出现了很多基于 LLM 的知识库思路，比如 LLM Wiki、知识图谱、先编译后检索。它们的共同点是：先让 LLM 参与知识编译，再把编译后的知识交给模型检索和调用。
理论上，LLM 参与编译后的知识，更适合 LLM 后续调用。
我也为正在开发的 Agent 产品建设了一套专门适配的知识库。思路更接近 LLM Wiki：先编译，再检索；先把知识整理成更适合模型理解的形态，让 LLM 可以分层读取，也可以通过本地命令快速检索。它更适合那些很难直接放进 Agent 上下文、又没必要使用 RAG 的场景（非海量知识的知识库场景）。
但核心必然是精调。
8. 接入 Git 仓库：成本很高，但价值很大
Git 仓库在产品类知识问答和研发 Agent 里价值很大。尤其是面向产研的 Agent，代码仓库几乎是绕不开的基础上下文。
很多产品逻辑、接口约束、页面实现、历史演进，其实都藏在代码里。文档可能过期，口头描述可能不准，但代码通常更接近真实系统。
Agent 一旦能接入 Git 仓库，就可以做很多有价值的事：
- 根据代码定位产品功能；
- 根据 diff 分析改动风险；
- 根据目录结构识别项目边界；
- 根据 commit 和分支理解研发上下文；
- 根据代码和文档交叉验证业务规则；
- 根据错误反馈和错误日志定位相关代码逻辑。
但 Git 仓库很难只在服务端处理。Git API 能做的事有限，适合查元信息、读文件、看 diff，但一旦涉及复杂检索、依赖分析、命令执行、测试运行，就必须把代码拉到本地环境里处理。
这里最大的问题是：Server Agent 不擅长处理本地工程环境。
像 Claude Code、Codex 这类端上 Agent，天然可以访问文件系统、执行命令、读取仓库、跑测试。但大多数企业级 Agent 都部署在服务端，外部能力主要靠接口调用，很难直接拥有这种本地工程能力。
所以我更倾向于把 Git 仓库能力抽成一个独立的远程本地 Agent，主 Agent 不直接处理仓库细节。
我比较推荐的做法是：
- 主 Agent：负责对话、业务流程、任务状态、权限和结果呈现；
- 远程本地 Agent：负责拉代码、切分支、检索文件、分析 diff、必要时跑命令或测试，也可以承载本地化知识库和代码索引。
这样做的好处是边界清楚。Server 侧保持轻量，真正依赖本地环境的能力交给远程本地 Agent 处理。
我在新的 Agent 产品设计里也采用了类似思路：把 Git 仓库作为上下文来源，把本地化能力抽象成独立子 Agent，部署在单独机器上。主 Agent 只负责把用户问题、任务状态和最终结果串起来，远程子 Agent 负责处理代码检索、本地知识库、日志分析等更贴近工程现场的能力。
这会明显降低 Server Agent 的设计复杂度，也让 Git 仓库能力更容易扩展。后面如果要从“代码问答”继续走到“代码修改”“测试执行”“生成 patch”，也可以在这个远程本地 Agent 上继续加权限、沙箱、回滚和审计，避免把复杂度都压到主流程里。
9. Agent 到底如何做测试？是否要写测试集？
要区分一件事：你到底是在做科研，还是在做产品？
LLM 领域有很多学术和研究语境里的测试概念，平时也经常能听到。比如模型生码能力怎么测，复杂 Agent 能力怎么设计评测集，如何通过不断调试 Agent 逻辑来提高测试集通过率和匹配率。
这些当然有价值，但我想说：给 LLM 相关能力做一套严谨测试集，是一件超级困难的事。（说实话大概率只是做做样子）
尤其是你想优化一个 Agent 细分能力时，测试集设计本身就是一项很重的工程。很多时候，做测试集的成本甚至要高于开发的成本。
在我看来，这更接近研究型工作。
但如果你是在开发产品，而且这个产品最后是给用户用的，就完全不一样，你应该注重产品级测试。
产品级 Agent 的最终体验受太多变量影响：交互入口、上下文质量、工具设计、任务状态、用户预期、权限、成本、延迟、历史任务、异常兜底。即使某个测试集通过率很高，距离用户体验也非常遥远。
这里没有那么强的因果关系，除非你在工程侧的优化已经做到了极致。
所以做 Agent 产品开发，我更建议做产品级测试：
- 核心流程能不能跑通；
- 用户入口是否自然，交互体验是否足够好；
- 上下文是否足够；
- Tool 调用是否稳定；
- 关键节点是否需要确认；
- 失败后有没有明确提示；
- 历史任务能不能继续引用；
- 权限、审计、灰度、回滚是否可控；
- 真实用户是否愿意继续用。
这类测试不一定漂亮，也不一定像论文里的 Benchmark 那么严谨，但它更接近产品真实问题。
如果你真的要验证某个技术优化，也要把验证范围收窄。比如你优化 RAG 召回，就验证召回质量；你做模型微调，就验证微调前后的特定能力变化；你改 Tool 参数，就验证 Tool 调用成功率和错误类型。
不要试图用一个大而全的数据集证明“产品最终能力变好了”。变量太多，验证不干净，也很容易自我安慰。
10. 为什么企业级 Agent 这么难落地？传统技术团队面临挑战
这两年我看到公司内外很多团队都在做 Agent 产品，但大多数结果都不太理想。原因当然很多，但我认为最基础的问题有两个：
- 到底要做什么：交付业务产品，还是包装一套 AI 技术 Demo？
- 到底谁来做：产品主导、技术主导，还是有人能把产品、工程和 AI 能力一起拉通？
第一件事前面已经反复讲过。我们真正要交付的，应该是业务场景里可上线、可复用、可持续迭代的产品能力。
我主要想聊第二件事。开发 Agent 产品，传统团队里往往缺两个关键角色。
- 缺少 Agent 技术研发：除了 LLM 基础知识，Agent 还要把概率性的模型能力和确定性的工程逻辑放在一起设计。传统程序员更擅长确定性的逻辑代码开发，过往经验不一定适用。
- 缺少 Agent 产品经理：Agent 本质上是强技术型产品。产品经理如果不理解模型边界和工程约束，很难把需求定义清楚。更麻烦的是，很多 AI 技术本身还在探索，普通产品更容易跟不上节奏。
项目跑偏通常就是从这里开始的。产品主导时，缺少 AI 技术的理解，需求很容易脱离现实；技术主导时，则非常容易变成能力拼装和技术自嗨。目前绝大多数 Agent 产品最终都会滑向这两个方向
那么当团队中既缺少技术，又缺少产品，怎么才能把产品做好？这是传统技术团队必须面对的挑战。
未来对 Agent 产品负责人的要求，很可能不再停留在单点岗位能力上，更偏向跨栈的底层能力组合。这也是今天提倡 AI 全栈能力的原因。
总结
企业级 Agent 最后拼的是交付能力，聊再多概念没有意义。
从 0 做一个 Agent 应用，先要搞清楚业务目标和产品边界，再决定技术怎么用。知识库、Skill、MCP、记忆、Git 仓库、框架都有价值，但它们只是链路里的工具。真正要交付的是产品能力，指望某个技术单点拉高整个 Agent，基本不现实。
所以别把 Agent 做成一个“全能 Demo” 或者技术自嗨的产物。企业级 Agent 真正要解决的是在明确业务场景里稳定完成任务，并把模型的不确定性收敛成可交付、可复用、可持续迭代的产品能力。
同时，未来能把 Agent 做好的人，需要同时理解业务、产品、AI 技术和工程约束的人，这也切合现在推崇的 AI 全栈工程师的岗位发展
原创声明
原创文章，转载请注明作者和文章原链接，插图来源 AI 生成，关注公众号看更多文章哦！
