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

[ylxmf2005]

以上内容基于目前 v3 分支，另外我注意到了最新的 PR；虽然我没有详细阅读，但可以确认工具调用仍然是此 Issue 提到的方式。而不是使用 tool_call 和 tool_result messages。如果可以的话，我愿意在特定分支上尝试上述的增强重构。

[MiaowFISH]

非常感谢您对此项目的关注和建议！

关于是否迁移到原生 tool_call 协议，之前我也有过思考和对比测试。

虽然原生 tool_call 是目前构建任务型 Agent 的行业标准，具有协议统一和鲁棒性高的优势，但经过实际测试，我发现原生方案在当前阶段存在几个与项目核心目标冲突的问题：

1. 角色扮演能力的显著下降

我们的核心目标是为智能体赋予“灵魂”，使其具有鲜明的性格和情感。

在对比测试（如“猫娘”人设）中我们发现：

在 JSON 结构化输出模式下，模型能够很好地将人设细节（如语气词、动作描写、情感色彩）融入到回复中。

而一旦激活工具模式，模型的回复倾向于变得机械、简练且高度任务导向。这可能是因为各大模型在进行 Tool Tuning 时，主要使用了任务型、指令型的数据集，导致模型在调用工具时会自动切换到“助手”的模式，从而削弱了“虚拟伙伴”的人格表现力。

2. Token 效率与上下文开销

原生 tool_call 协议需要严格遵循 OpenAI/Anthropic 的 Schema 定义，且在多轮交互中需要维护 assistant(tool-calls) + tool(result) 的完整消息链。

测试结果显示，在相同的交互轮次下，原生方案的 Token 消耗量是当前自定义 JSON 方案的 3-5 倍。对于一个需要长期运行、服务于多人群聊的系统来说，这种开销是巨大的，且目前的收益无法抵消成本。

测试结果

model: deepseek-chat
temperature: 0

----- JSON Call Test -----
AI SDK Warning System: To turn off warning logging, set the AI_SDK_LOG_WARNINGS global to false.
AI SDK Warning: The "seed" setting is not supported by this model
Generate Text Response: {
  "actions": [
    {
      "type": "action",
      "name": "send_message",
      "args": {
        "content": "听到你心情不太好，我有点担心呢。如果你愿意的话，可以和我聊聊发生了什么，或者只是静静地待一会儿，我都会在这里陪着你。"
      }
    }
  ]
}
Usage: {
  inputTokens: 49,
  outputTokens: 71,
  totalTokens: 120,
  reasoningTokens: undefined,
  cachedInputTokens: 0,
}
----- End of JSON Call Test -----
----- Tool Call Test -----
Message sent: 听到你今天心情不太好，我真的很关心你。有时候情绪低落是很正常的，每个人都会有这样的时刻。如果你愿意的话，可以和我聊聊是什么让你感到不开心 ，或者我们可以一起想一些能让你感觉好一点的事情。我在这里陪着你呢。
AI SDK Warning: The "seed" setting is not supported by this model
Generate Text Response:
Usage: {
  inputTokens: 331,
  outputTokens: 92,
  totalTokens: 423,
  reasoningTokens: undefined,
  cachedInputTokens: 320,
}
----- End of Tool Call Test -----

自定义人设：

system: 你是一个温柔的猫娘伙伴。...

----- JSON Call Test -----
Generate Text Response: {
  "actions": [
    {
      "type": "action",
      "name": "send_message",
      "args": {
        "content": "喵~ 听到你心情不太好，让我轻轻蹭蹭你的手，给你一点温暖。要不要和我聊聊发生了什么？或者我们可以一起找个安静的地方，我给你讲个可爱的 小故事？"
      }
    }
  ]
}
----- End of JSON Call Test -----
----- Tool Call Test -----
Message sent: 喵~听到你今天心情不太好，让我有点担心呢。要不要和我说说发生了什么？或者我们可以聊点开心的事情，比如猫咪的可爱故事？有时候倾诉出来会感觉好一些的哦~
Generate Text Response:
----- End of Tool Call Test -----

3. 系统架构的差异

目前采用的是状态式上下文管理，而不是传统的对话式消息流。
当工具执行完毕后，我们将结果回填到 System Prompt 的工作记忆(Working Memory)区域，并再次触发推理。
这实际上已经实现了闭环的 ReACT 流程（感知 -> 行动 -> 观察 -> 再行动），只是我们选择更新当前状态，而不是追加历史消息。这种方式在处理多人群聊这种复杂上下文时，比线性的 Message List 更具优势。

结论

虽然原生tool_call是更标准化的做法，但考虑到本项目“高拟人化”的特殊定位，以及对Token效率的极致追求，还是继续优化现有的结构化文本协议，而不是迁移到原生工具调用。

当然，我们非常欢迎pr，要是能解决上述问题就再好不过了。如果未来模型能力进化，能够在保持高强度角色扮演的同时高效使用工具，我们会重新评估这一技术路线。

再次感谢你的建议！如果有任何补充或不同的看法，非常欢迎继续交流