就是 领导现在看别的系统都接入了ai 我们有个类似低代码的系统 后端他们现在已经搭建了一个Hermes 有一下的场景
1.如图一是外层应用管理 这里可以在右下角有个聊天的窗口可以可以去比如让ai 去创建应用 创建表单 等一切可以操作的 这里我理解的是 可以把操作我们表单的东西 作为一个mcp服务端 注册进Hermes 让Hermes 自行选择工具调用
2. 图二是应用内部表单的管理 同1 只不过这里应该给Hermes 的上下文会带上此应用的一些信息
3.图三 是表单的设计页面 这里的设计是这样的 左侧是表单设计 右边是聊天框 但是需要左边去实时的显示 比如ai理解要加一个字段左边要实时的展示
求助：我的理解Hermes 已经是一个Agent 他会loop 但是图三那种不也需要前端调用工具 然后上报工具的结果 这不也是loop 给整不会了
谁看懂他说的了，我只看出你的问题是有关loop的。
要么你前端自己根据业务场景做自己的 Agent，然后对接你们后端的 Agent。
要么就是你让后端梳理清楚，告诉你后端需要前端提供什么参数，让后端的 Harness 去调配。
实时场景可以让Hermes考虑用独立脚本服务，或者使用心跳服务，去监测会话内容，给出显示建议（或者调整建议）然后前端渲染。
如果想更简单一些，就是改一下会话返回结构，会话返回包含：输出内容+按钮展示建议，前端分别展示输出内容，调整左侧建议按钮。
我不理解的是比如：Hermes说要增加一个字段，前端加好了 怎么通知Hermes前端加好了 继续让Harness 进行loop
这个肯定要传给后端接口的吧,这样通过后端接口传给Agent,Agent再进行回复吧,按道理来说:
用户:增加一个表单
Agent:调用模型或skill生成对应的代码=>传给前端展示
用户:看到了增加了表单
=====
按道理应该是这个流程吧
可以看一下 vercel ai sdk。
我们现在做的也是这种编辑器，是客户端工具执行架构。
因为编辑器的内容只存在于前端浏览器中，后端去执行这些东西就不现实。
前后端统一一套工具契约，用的 vercel ai sdk 是会有一个回调函数回传 tool result 返回给后面的 agent 的。
[前端] onToolCall 收到 get_component_tree
→ executeTool() → 遍历 GrapesJS 组件树 → 返回结果
→ addToolOutput() 回传 tool result
// 2. 使用 AI SDK 的 useChat() 管理对话状态
const { addToolOutput, messages, sendMessage, status, stop } = useChat({
transport,
sendAutomaticallyWhen: lastAssistantMessageIsCompleteWithToolCalls, // 自动发送工具结果
async onToolCall({ toolCall }) {
// 3. 工具调用回调：根据风险等级决定执行或等待确认
if (needsConfirmation(toolCall.toolName, approvalMode)) {
setPendingMutation({ ... }); // 等待用户确认
return;
}
await runToolCall(toolCall.toolName, toolCall.toolCallId, toolCall.input);
},
});
这不是要跟页面需要审批的逻辑差不多么 agent-> 输入给到前端 → 前端渲染状态 → 后端接口 =>agent
我理解这样的话是一次性的对话，就不是Agent了 比如ai做了一些表单的更改需要用户去确认ai在去干下一步
并不是一次性的呀,只要有上下文给Agent,那么他就可以继续下一步,不管是确认与否还是下一步执行其他内容,只要在当前的聊天中,有上下文就可以了吧.其他的工具也是这样的呀,前端拿到上下文和用户的新内容,传给后端,后端给模型,根据模型返回的内容渲染或处理…,应该都是一样的吧.
嗯 理解佬的这是客户端的Agent，我们这个可能还有这样的需求比如 “绑定某一个表单为多对一关系 这时候应该会有个工具去查询另一个表单的一些信息 这样的话是不是所有的工具都需要写在客户端”
我没看懂，你前面说你们搭了个hermes，我的理解是把这个系统包装成skills让hermes调用。后面的说法又像是直接在你们系统上开发一个agent
不理解，怎么就不是Agent了？
明白佬的思路了 佬也是把工具放到客户端客户端来做 但是现在我们后端搭建了一个Harness 后端懒省事直接进行了接口的转发
可以的啊，很多操作你都可以封装为 tool 然后就可以查数据通过addToolOutput回传给本次的 agent 了。
但我觉得 tool 弄多了似乎也不好，这个看你业务吧。
我们定了二十多个 tool 提供给 ai 来操作我们的画布工作区。
这样的话Harness Agent是不是就没有意义了
后端就是偷懒，脏活累活前端来干 
但是这中操作界面的确实也得需要前端来干，我其实不太明白的是这种既需要使用调接口的工具 又需要操作界面的工具， 该如何去组合， 还是如果有操作界面只能都放在客户端
我不确定你们后端是怎么实现的，但我认为这种业务需求是需要自己开发后端的那些部分。
我们现在用的 vercel ai sdk 比较轻量级，还有那些更复杂的 langgraph 之类的东西我还没看。
我这边后端直接用那个 sdk 里的streamText就能满足我的需求了。。。