Feature: 是否考虑用更标准的 Agentic Loop 来增强现有的 Heartbeat

[ylxmf2005]

Describe the problem related to the feature request

目前 Athena 的 Agent 执行逻辑基于 HeartbeatProcessor：每次心跳由 LLM 输出一个自定义 AgentResponse JSON（包含 thoughts、actions[]、request_heartbeat），再由宿主侧顺序执行所有 actions。

1. 工具调用协议完全依赖提示词约定，LLM 需要“自己产 JSON”，稳定性受限；
2. 同一轮心跳内的工具调用是开环的，工具结果不会回流到当前 LLM 推理中，不利于复杂多步任务。

Describe the solution you'd like

在单次心跳内部使用 LLM 原生的 tools 机制实现 agentic loop，大致流程:

1. 仍然使用现有 PromptContextBuilder 构建 world state / memory / 历史消息，生成初始 messages。
2. 调用支持 tools 的模型接口。
3. 如果模型返回一个或多个 tool calls：通过现有 ToolService.invoke() 执行实际工具；将 tool_call 及其结果封装为新的 message（类似 assistant(tool_call) + tool(result)）追加到 messages；记录 action / observation 日志；再次调用 LLM，进入下一轮循环，直到输出最终回复或达到最大步数。Heartbeat 参数（config.heartbeat）仍可保留，作为“每次 stimulus 最大思考回合数”；每一回合内部使用上述 tool call loop 模式。
4. 对于需要挂起的长任务，由工具返回 task_id + status: pending，agentic loop 结束当前回合；任务完成后通过系统事件 / cron 再触发新的 agent/stimulus，由新的回合继续对话。

预期收益:

• 不再依赖提示词内的手工 JSON 协议，减少提示词耦合和解析错误；
• 直接利用各大模型对 tools 的原生支持，提升工具调用的准确率和鲁棒性；
• 支持真正闭环的工具调用 -> 结果回流 -> 下一步决策，更适合复杂任务；

Describe alternatives you've considered

类似问题已在 #149 #150 #151 提出

Additional context

No response