.2026-05-23 来自四川这是 react 模式吗？感觉像 workflow。这个规划引擎似乎并不适合动态规划类型的任务，即一些几乎没办法硬编码过程的任务。所以如果说框架通过这个规划引擎能够节约 token 其结论似乎不成立。不知道是否是理解有误作者回复: 你好，Embabel默认使用GOAP算法进行规划，这是一种不依赖LLM的人工智能算法，不属于是ReAct模式，就规划而言并不会产生token消耗。当然在每个具体action里可能会存在LLM调用，这种调用我们不把它当做规划的一部分。另外，GOAP和workflow存在较大区别，workflow确实需要硬编码具体过程，但是GOAP会智能地自动地进行规划，关于GOAP我们会在核心篇的06讲有更多介绍。
大魔王汪汪2026-05-22 来自北京我们自己基于langgraph思想写了一个java版本，当然也抛弃了一些原有langgraph我们认为不太优雅的方案。看下来Action和Langgraph中的node很像，既可以直接做工具，也可以作为逻辑封装，可以像工具一样被LLM发现。黑板和State思想是一致的，Langgraph并不一定是状态机可以用类似于reflection的思路实现非状态机驱动。这个Goal的设计思路很好，可以借鉴一下，用于一些确定性的目标场景，这样可以提升agent反思的效率。作者回复: 赞！自己实现框架可以掌握更多的细节，完美适配自己的需求，很适合技术实力强的团队。在本课程核心篇的06讲和09讲，我们会分别介绍GOAP以及Utility AI 和 Supervisor这三种规划方式，希望能让您有所收获。
瀚海2026-05-22 来自浙江不太理解embabel, 使用embabel有几点担心: 1. embabel怎么决定执行路径的？大模型参与决策了？会不会造成决策死循环？会不会造成执行路径难以追溯复现 2. 代码控制能力下降，执行不可控 blackboard是不是可以理解为之前的有限状态机 3. 看ooda流程比较固化，真的能适应生产环境各种各样的需求变动吗 产品的思路常常很难琢磨，会不会陷入领域驱动一样的困境 需要不停抽象逻辑来适应，造成代码难以维护和团队内难以达成共识作者回复: 你好，我来逐一回答您的问题。 1.Embabel框架在默认情况下，使用GOAP算法进行规划，也就是决定执行路径。此算法属于人工智能算法中的一种，但此过程中并没有大模型参与决策，在合理编码的情况下不会出现决策死循环的情况，执行路径是可以追溯复现的，这其实正是Embabel的一个独特优势，更多的细节我们会在核心篇06讲做更多介绍。 2. Blackboard（黑板）是一个供Agent、业务代码和规化算法共同读写信息的“共享内存空间”或“公共工作区”。 假设有一群专家聚在一起要解决一个复杂的商业任务（比如“帮客户退货并分析退货原因”）。 它是公共小黑板：大家不直接交头接耳，而是把各自发现的线索、当前拿到的数据（比如：订单号、客户情绪、库存状态）全部写在墙上的黑板上。 算法也通过它来认路：Embabel 内部有一个不依赖大模型的智能路径规划器（GOAP Planner）。它会走近这块黑板，看看上面写了什么（也就是当前世界状态 WorldState），然后决定下一步该派哪个专家（Action）去干活。 干完活把结果写回来：被派出去的专家执行完任务后，把新得到的数据（比如：确认已退款成功）再写回黑板，并擦掉已经过时的信息。黑板更新了，规划器就会据此规划下下步，直到最终目标达成。 3.OODA算是理论基础，实际的具体实现我们看GOAP算法，这个算法虽然不依赖LLM, 但是其实还是很智能的，并且它已经被框架实现好了，我们开发者在实际开发中只需要通过声明式编程定义Action, Condition, Goal这些就可以了。