AI Agent 就是后端微服务

很好的分析和归纳，感谢楼主！
对于prompt的解释归于业务逻辑，在这里的业务逻辑是在具体说哪些内容？因为传统的业务开发逻辑空间是封闭的，可以穷举出所有分支。但是prompt的语义完全开放，相当于放弃了所有路径的枚举权？
对于memory，我完全赞同新的问题是什么值得存，因为传统系统存什么是确定的。
最后对于eval，judge 本身又需要 eval确实是个值得讨论的地方，因为按照个人的经验，传统的QA很依赖可以reproduce，不知道agent时代怎么确定是个真bug。

写的很好，ai agent就是新时代普通后端sde呢。

写得很好啊啊啊啊啊

woshiwopa 发表于 2026-6-15 07:39
Agent如果做成单一功能微服务，那Agent的价值在哪呢？有点马拉火车的感觉。
在系统设计甚至是公司业务层面 ...

好问题，我的理解是有些传统代码无法解决的问题，必须依赖有inference能力的LLM执行。

最典型的比如客服，对自然语言处理的能力要求很高，但你不希望整个流程很不受控，所以入口可能是LLM分析语义，之后根据情况进入一个deterministic workflow 查文章，开 ticket等，最后有非常可控的输出。

这里要明确，agent不一定只做成单一功能的微服务，可以多个agent组合在一起互相调用。但我依然认为一个最小单元的llm infernce agent只做一件小事的设计是没有问题的。

persist2020 发表于 2026-6-17 08:13
很好的分析和归纳，感谢楼主！
对于prompt的解释归于业务逻辑，在这里的业务逻辑是在具体说哪些内容？因为 ...

我认为 prompt 和 workflow 都可以归纳成业务逻辑

workflow 类似

- 通过用户语义判断用户意图，提前设定意图种类
- 如果是种类1，进入分支1，对应的行为逻辑可能是一段代码开一个ticket
- 如果是种类2，则进入分支2，对应的行为逻辑是查询知识库直接回答

所以这种融入LLM的workflow本身就是一种业务逻辑的一种展现。

而如果细看第一步“ 通过用户语义判断用户意图”本身也可以是业务逻辑。只不过在前LLM时代，判断用户意图可能要你在前端写一个dropdown，让用户自己把意图明确表达出来，或者写代码做一些NLP进行关键词检测，从而推测意图。现在LLM可以更好更高效的把这事做了

听风流水york 发表于 2026-6-15 09:24
深表认同。 一点疑惑: 这么看下来做agent研发， 是MLE，还是SDE合适呀？
我是MLE做agent开发， 感觉就是在 ...

我公司确实是普通SDE，补习一大堆agent相关知识后，转做 ai agent 开发比较多。

我个人认为MLE的 domain knowledge 还是挺不一样的，我公司的MLE做的依然更多还是理数据，做实验之类的活，不太会开发 agent product

不同公司 MLE 和 SDE 的分野很不一样，很看公司本身的职责划分。

riotamago 发表于 2026-6-17 07:42
好问题，我的理解是有些传统代码无法解决的问题，必须依赖有inference能力的LLM执行。

最典型的比如客 ...

感觉你的思路是偏workflow的路线，把LLM包在节点里面，整个流程是确定的。这个设计思路限制了LLM价值的最大化。单一的workflow不能适应所有的情况，新的情况出现就要去改workflow，LLM并没有解决这个问题。
我说的以LLM为核心的设计重点就是把所有的不确定情况都内化到LLM，确定的逻辑/功能放到外层作为工具调用。拿claude code举例，它并没有一个workflow讲先干什么再干什么，只是给LLM提供了20多种工具。这些工具内部是没有LLM的，只是被调用和返回结果。
这样的设计给了claude code足够的可扩展性，不仅仅可以用于开发，对其它类型的工作也能适用。

精彩的类比和总结！

今年围绕Agent火起来的话题貌似是铺天盖地地探讨Agent Harness。之前的multi-agent就像是monolithic app，有个比方就是好比你把方向盘、传动和GPS等等这些统统和引擎都焊接在底盘上；结果就是开得顺畅、或是翻车等等这些你都无法很容易抽丝剥茧来分析。而这个技术方面的问题就是类似过去巨石应用面临的问题，结果就是微服务的思路，这样一来就容易独立出影响性能的各个参数/子系统/指标出来，是prompt、还是memory管理、或是因为缺少observability而无法精准拍错或改善性能等等。另一个引起这个问题的人为因素是，大家一开始都是一窝蜂地用一些类似黑盒子的框架去抢着做POC做演示，使用缺省参数，过分依赖模型的性能，而未意识这些周边但却是同样重要因素的影响。。。

非常认同。目前如果只是做product的AI Engineer，主要还是SDE的技能栈

woshiwopa 发表于 2026-6-18 08:07
感觉你的思路是偏workflow的路线，把LLM包在节点里面，整个流程是确定的。这个设计思路限制了LLM价值的最 ...

确实，你所说的这样的方案我也认可是最理想的，同是也是最“agentic”的，让agent自己决定什么时候用什么工具做什么。

我在业务上遇到的问题是这样的结果非常不可控（很取决于你的业务本身是否有非常高的流程需求，还是天生就允许多一些flexibility），而对其做online/offline eval和然后再不断提高的成本很高，所以最终演变成了只在有reasoning或者inference需求时（往往意味着自然语言的分析，无论是分析用户自然语言输入还是分析研报文章等），动用一下LLM，且几乎一定以structured output的形式输出，喂给之后的流程。之后的流程根据schema做传统代码形式的definite work，比如把一些数据加到数据库里等。

我认为对ai的使用的确是个spectrum，我目前做的还是比较保守的。