浅谈这段时间开发 AI Agent 的局限性和难点

1：LLM + Tools 局限性：
- 常见场景：Chatbot 为主的（FuntionCall、MCP）
- 局限性：长链路的延迟和幻觉、多步骤的模型注意力有限、上下文受限、工具规模管理问题、Tools 与模型相互弱化。缺少记忆、规划、流程管理的能力，Agent 状态持久化开发成本高，单次 LLM 处理能力有限，多轮对话上下文太高

2：LLM + Tools + Memory（代表 langchainJS）
- 场景：存储用户对话和个人偏好、以及使用习惯等等个性化场景，成为用户的第二分身。
- 局限性：见第 1 点，缺少复杂流程链路的管理，比如某个节点出现问题、中断、循环问题（比如生成代码）、hunman介入，无法从原来的位置恢复，分支逻辑等等

3：LLM + Tools + Memory + workflow（代表 langgraphJS）
- 场景：类似于 Manus、Genspark 代表等等 Planing Agent
- 局限性：对上下文要求高，需要训练小模型，大量的工具维护与开发，对资源需求很高、还要设计复杂的 AgentState，需要贯穿整条workflow，可能还涉及子图，前后端协议

4：LLM + Tools + Memory + workflow + Protocol（Google Adk + A2A协议）
- 场景：富文本信息流（AI 每条消息可能有长文本、视频、图像、文件等）类似于 Manus、Genspark 信息流。
- 局限性：需要对接与设计 Agent 2 Agent 之间和 富文本 UI 的数据协议，特别是数据流的前后端的时序处理（细节特别多），复杂度和开发成本高，需要训练更多的数据来提升增强每一个环节的效果。

我个人认为第 4 点的难点在于对于复杂业务系统的实现，常见的是代码生成。需要具备指定场景的项目经验，构建架构和模板项目提供样板支撑，才能保证每次生成的效果非常好。且每次涉及Bug调整和修改都有可能进入死循环（参照 cursor / cline）

抛砖引玉，有限的经验分享