Phidata项目Team Agent在REST API调用中的上下文丢失问题解析

在基于Agno框架（版本1.1.15）的团队协作型AI代理开发中，开发者kasem-io报告了一个关键性的上下文保持问题。该问题表现为：当使用Team Agent配合Postgres存储后端时，控制台交互模式能正常维护会话上下文，但通过REST API调用时会出现上下文断裂现象。

问题本质

Team Agent的设计初衷是通过enable_team_history参数启用历史对话记忆功能，配合session_id和user_id实现多轮对话的上下文保持。在底层实现上，系统依赖PostgresStorage进行对话状态的持久化存储，理论上无论通过控制台还是API调用，只要session_id一致就应该保持对话连续性。

实际故障表现为：

1. 控制台交互时，num_of_interactions_from_history参数配置的历史消息数（示例中为5条）能正常生效
2. REST API调用时，尽管传入相同的session_id和user_id，Agent却无法读取历史对话记录
3. 跨子Agent（appointment_agent/calories_agent等）的对话流出现中断

技术背景

在团队协作型Agent架构中，上下文保持涉及三个关键层面：

1. 存储层：PostgresStorage负责对话记录的持久化
2. 路由层：Team Agent作为协调者管理子Agent的调用
3. 会话层：通过session_id实现的对话隔离机制

典型的问题根源可能存在于：

• 存储层的会话隔离实现存在缺陷
• REST API调用路径中缺少必要的上下文注入点
• 历史消息加载逻辑在API模式下未被正确触发

解决方案

项目维护者dirkbrnd在版本1.2.3中修复了该问题。从技术实现角度推测，修复可能涉及：

1. 统一化控制台和API模式下的历史记录加载机制
2. 加强Team Agent对子Agent历史记录的聚合能力
3. 修复PostgresStorage在无状态环境下的会话恢复逻辑

最佳实践建议

对于类似的多Agent系统开发，建议：

1. 会话一致性验证：在启用历史功能后，应当编写测试用例验证跨模式（控制台/API）的会话保持
2. 存储层监控：对Postgres的查询日志进行监控，确认历史记录的实际加载行为
3. 上下文注入检查：确保REST API网关正确传递所有会话标识参数

该案例揭示了分布式AI系统中状态维护的典型挑战，也为复杂Agent架构的调试提供了重要参考。版本升级后的实际测试表明，在保持相同session_id的前提下，API模式现已能够正确维护包含子Agent调用的完整对话上下文。