请教佬们一个问题，如何构建一个生产级agent
- 内容介绍
- 文章标签
- 相关推荐
最近工作中接了几个agent开发的项目，主要用在提高工作人员的工作效率方面，一开始用的是公司部署在阿里云的dify，通过工作流或者对话机器人加知识库构建专属agent，可是现在觉得dify的方式有点死板，适合快速做一个demo，里生产级别的还是有点距离。
接着最近慢慢了解到了Langchain Langgraph AutoGen AutoScope等Agent框架，优缺点也有了一下了解，但其实还是很纠结到底应该怎么入手，不知道这方面站内的大佬们有什么开发经验吗？
或者有什么项目推荐学习一下的吗？
--【壹】--：
可以看看github上pi-mono这个项目，openclaw也是从这个上一点一点做起来的
--【贰】--：
有在公司服务器上部署 agent 的大佬吗，梯子怎么搞合规
--【叁】--：
claude源码等着你去构建呢 还有openai不是开源的吗。多的是~
--【肆】--：
谢谢佬，受益匪浅！说到底我觉得我对业务还是不够了解，这也是我需要加强的地方。
--【伍】--：
正好最近也有相关项目的想法，前排mark，蹲蹲佬友们的回答
--【陆】--：
mark 下，蹲一蹲各位佬友们的思路
--【柒】--：
参考 openclaw hermes claudeCode 的源代码？
--【捌】--：
mark 下，蹲一蹲各位佬友们的思路，听说记忆提取向量化之后召回的准确率不高是不是真的
--【玖】--：
以我不多的经验来看，主要下面几个思路：
- coding交给 AI，需要详细的 review plan，包括接口如何设计结构体如何设计等等，心里要有数。
- 了解业务，深度了解业务，这直接决定了 AI 的产物最后和你预期的偏离程度。如果你不了解业务，后面会反复重构，因为业务的需求直接影响了 Agent 的实现。
- 落地的业务文档，这是对第二点的衔接，当你深入了解业务之后，和 AI 讨论业务的设计和实现，落实成一个 PRD.md，这是之后 vibe coding 的基石。
- 技术路径，这是需要你根据自己的经验和 AI 深入业务讨论之后做出的决策。比如用不用 langchian，用不用 langgraph，需不需要 cache 需不需要 redis，数据库用什么，非结构化数据怎么查等等。和 AI 聊完你自己也有数了，觉得可实施就落实成 TECH.md
- 具体实现方案，vibe coding 让 AI 根据 PRD.md和 TECH.md生成可执行的 Plan，第一次的总体架构 Plan 一定要好好 review，这是之后一切的基石。
- 然后业务准确性，ReAct Agent 对基模的能力依赖非常大，就算是顶级模型，把业务全部交给 ReAct Agent 自己决策，你提供 Tool，这在 Demo 阶段可以，但是上了生产很容易因为各种各样的原因难以控制 Agent 回答的准确性，这点在数据查询这种要求准确性的需求上尤为明显。
- 可以考虑使用 Planner + Workflow + reviewer 的形式，把需要精确查询的场景落地成多个 workflow 模板，让 Agent 根据用户的查询进行参数提取，智能路由到对应场景的 Workflow，让 Agent 去做选择而不是完形填空
- reviewer 或者 fallback 的设计，这点看具体业务需要，对于查询时间不敏感的，可以考虑加上一个塞了完整业务上下文的 Agent 对Workflow 的结果进行打分，高置信度返回给用户，低置信度则 fallback 给 Planner 建议重查或者让 ReAct 兜底等等。这个要看自己的业务需求。对于查询时间敏感的，需要保证 Planner 阶段的意图分析和参数提取就是正确的，低置信度的要求用户澄清拒绝执行，只有上下文清晰再去调用 workflow 执行，这样大概率可以保证一次性输出正确结果，并且执行时间很短。
- 对于业务术语，可以考虑多层匹配，比如首先本地文档内置业务术语，业务术语在数据查询上可能体现为用户的黑话对应的字段，这一步通过对内置术语 mapping 使用关键词或者模糊文本匹配的算法提取，如果提取不出来可以考虑 fallback 到其他路径，比如 RAG，通过语义提取。
以上是我的一些经验，总的来说几句话：
- 深度了解业务，知道你要做的是什么，输入什么、产出什么、中间过程的复杂度
- 让 Agent 做选择题而不是填空题
- 符合业务需求的兜底方案
--【拾】--：
最近我也尝试自己做一个，但没什么头绪，怎么学比较好
--【拾壹】--：
可以参考openclaw，用ReAct这样的通用Agent设计是比较快，也不太容易出大问题的。
--【拾贰】--：
mark 下，蹲一蹲各位佬友们的思路 或者比较强的开源项目
--【拾叁】--：
dify就不是agent，是工作流
agent基础的原理挺简单，就claude code那样
LLM配上工具多轮执行完成任务
然后再慢慢去加记忆、改进提示词工程、上下文管理这些的
--【拾肆】--：
不知道你所谓的生产及agent是什么,如果是目标不偏移,只需要提需求,它能很准确的解读你的意图,并且实现是根据你框架进行,而且上下文衔接无偏差,那需要点东西,目前市面上大部分方案都不满足,原因是他们没有告诉你真正的长期项目迭代升级的真东西,这个方向是我主攻,因为我目前维护的项目是可以长期迭代的,只需要提需求就可以一直做下去
--【拾伍】--：
这个仓库我也在学但未学完，问下你觉得这个仓库有什么不足吗
--【拾陆】--：
蹲蹲，我最近也在做这方面的项目，感觉自己的设计和闭源市场里的成品差好多
--【拾柒】--：
前排mark跟帖学习一下，等大佬们冒泡回复
--【拾捌】--：
分享我入门学习的一个仓库文章，可以对构建agent有一个比较基础快速的认识 Hello-Agents
--【拾玖】--：
在多说一句，就是在设计 Agent 应用的时候，要把 Agent 当做一个比较聪明的学舌鹦鹉，而不是一个会思考的专家。当前 LLM 的实现注定了 LLM 不会真正的思考，而是通过自身庞大的预训练权重矩阵+你提供的上下文+用户的查询鹦鹉学舌，所以上下文的控制也是非常重要，让 Agent 做选择题而不是填空本意也是对上下文的控制，而不是依赖 LLM 的思考
最近工作中接了几个agent开发的项目，主要用在提高工作人员的工作效率方面，一开始用的是公司部署在阿里云的dify，通过工作流或者对话机器人加知识库构建专属agent，可是现在觉得dify的方式有点死板，适合快速做一个demo，里生产级别的还是有点距离。
接着最近慢慢了解到了Langchain Langgraph AutoGen AutoScope等Agent框架，优缺点也有了一下了解，但其实还是很纠结到底应该怎么入手，不知道这方面站内的大佬们有什么开发经验吗？
或者有什么项目推荐学习一下的吗？
--【壹】--：
可以看看github上pi-mono这个项目，openclaw也是从这个上一点一点做起来的
--【贰】--：
有在公司服务器上部署 agent 的大佬吗，梯子怎么搞合规
--【叁】--：
claude源码等着你去构建呢 还有openai不是开源的吗。多的是~
--【肆】--：
谢谢佬，受益匪浅！说到底我觉得我对业务还是不够了解，这也是我需要加强的地方。
--【伍】--：
正好最近也有相关项目的想法，前排mark，蹲蹲佬友们的回答
--【陆】--：
mark 下，蹲一蹲各位佬友们的思路
--【柒】--：
参考 openclaw hermes claudeCode 的源代码？
--【捌】--：
mark 下，蹲一蹲各位佬友们的思路，听说记忆提取向量化之后召回的准确率不高是不是真的
--【玖】--：
以我不多的经验来看，主要下面几个思路：
- coding交给 AI，需要详细的 review plan，包括接口如何设计结构体如何设计等等，心里要有数。
- 了解业务，深度了解业务，这直接决定了 AI 的产物最后和你预期的偏离程度。如果你不了解业务，后面会反复重构，因为业务的需求直接影响了 Agent 的实现。
- 落地的业务文档，这是对第二点的衔接，当你深入了解业务之后，和 AI 讨论业务的设计和实现，落实成一个 PRD.md，这是之后 vibe coding 的基石。
- 技术路径，这是需要你根据自己的经验和 AI 深入业务讨论之后做出的决策。比如用不用 langchian，用不用 langgraph，需不需要 cache 需不需要 redis，数据库用什么，非结构化数据怎么查等等。和 AI 聊完你自己也有数了，觉得可实施就落实成 TECH.md
- 具体实现方案，vibe coding 让 AI 根据 PRD.md和 TECH.md生成可执行的 Plan，第一次的总体架构 Plan 一定要好好 review，这是之后一切的基石。
- 然后业务准确性，ReAct Agent 对基模的能力依赖非常大，就算是顶级模型，把业务全部交给 ReAct Agent 自己决策，你提供 Tool，这在 Demo 阶段可以，但是上了生产很容易因为各种各样的原因难以控制 Agent 回答的准确性，这点在数据查询这种要求准确性的需求上尤为明显。
- 可以考虑使用 Planner + Workflow + reviewer 的形式，把需要精确查询的场景落地成多个 workflow 模板，让 Agent 根据用户的查询进行参数提取，智能路由到对应场景的 Workflow，让 Agent 去做选择而不是完形填空
- reviewer 或者 fallback 的设计，这点看具体业务需要，对于查询时间不敏感的，可以考虑加上一个塞了完整业务上下文的 Agent 对Workflow 的结果进行打分，高置信度返回给用户，低置信度则 fallback 给 Planner 建议重查或者让 ReAct 兜底等等。这个要看自己的业务需求。对于查询时间敏感的，需要保证 Planner 阶段的意图分析和参数提取就是正确的，低置信度的要求用户澄清拒绝执行，只有上下文清晰再去调用 workflow 执行，这样大概率可以保证一次性输出正确结果，并且执行时间很短。
- 对于业务术语，可以考虑多层匹配，比如首先本地文档内置业务术语，业务术语在数据查询上可能体现为用户的黑话对应的字段，这一步通过对内置术语 mapping 使用关键词或者模糊文本匹配的算法提取，如果提取不出来可以考虑 fallback 到其他路径，比如 RAG，通过语义提取。
以上是我的一些经验，总的来说几句话：
- 深度了解业务，知道你要做的是什么，输入什么、产出什么、中间过程的复杂度
- 让 Agent 做选择题而不是填空题
- 符合业务需求的兜底方案
--【拾】--：
最近我也尝试自己做一个，但没什么头绪，怎么学比较好
--【拾壹】--：
可以参考openclaw，用ReAct这样的通用Agent设计是比较快，也不太容易出大问题的。
--【拾贰】--：
mark 下，蹲一蹲各位佬友们的思路 或者比较强的开源项目
--【拾叁】--：
dify就不是agent，是工作流
agent基础的原理挺简单，就claude code那样
LLM配上工具多轮执行完成任务
然后再慢慢去加记忆、改进提示词工程、上下文管理这些的
--【拾肆】--：
不知道你所谓的生产及agent是什么,如果是目标不偏移,只需要提需求,它能很准确的解读你的意图,并且实现是根据你框架进行,而且上下文衔接无偏差,那需要点东西,目前市面上大部分方案都不满足,原因是他们没有告诉你真正的长期项目迭代升级的真东西,这个方向是我主攻,因为我目前维护的项目是可以长期迭代的,只需要提需求就可以一直做下去
--【拾伍】--：
这个仓库我也在学但未学完，问下你觉得这个仓库有什么不足吗
--【拾陆】--：
蹲蹲，我最近也在做这方面的项目，感觉自己的设计和闭源市场里的成品差好多
--【拾柒】--：
前排mark跟帖学习一下，等大佬们冒泡回复
--【拾捌】--：
分享我入门学习的一个仓库文章，可以对构建agent有一个比较基础快速的认识 Hello-Agents
--【拾玖】--：
在多说一句，就是在设计 Agent 应用的时候，要把 Agent 当做一个比较聪明的学舌鹦鹉，而不是一个会思考的专家。当前 LLM 的实现注定了 LLM 不会真正的思考，而是通过自身庞大的预训练权重矩阵+你提供的上下文+用户的查询鹦鹉学舌，所以上下文的控制也是非常重要，让 Agent 做选择题而不是填空本意也是对上下文的控制，而不是依赖 LLM 的思考