AWS AgentCore 搭 Chatbot 的真实体验：会话管理和上下文上限并非开箱即用
作者是 在线疯狂 发布于 2026年8月1日 在 AWS, LLM, Python, 碎碎念.

背景：从一次选型讨论说起

最近在评估用 AWS AgentCore 来搭一个 chatbot。官方文档把它描述成一个"企业级 agent 平台"，看起来什么都有：Runtime 跑代码、Memory 管记忆、Gateway 接工具、Observability 看观测。但当我真正去核对"会话管理"和"确保上下文不超模型上限"这两个 chatbot 最核心的需求时，发现 OOTB（开箱即用）的程度和宣传里暗示的并不完全一致。这里把结论记下来，供同样在选型的人参考。

AgentCore 到底是不是 chatbot 框架？

先说定位：AgentCore 是"运行时 + 记忆 + 网关"平台，不是开箱即用的 chatbot 框架。你需要自己写 agent 的业务逻辑（跑在 AgentCore Runtime 里），它负责的是部署、扩缩容、身份认证、工具连接和可观测性。对话和会话能力由其中的 AgentCore Memory 模块提供。

也就是说，它给你的是"地基"和"水电煤"，不是"精装修的房子"。对想快速拖一个聊天窗口的人来说，它偏底层；对要自己掌控 agent 行为、又要生产级运维能力的团队，它合适。

Conversation Management：OOTB 吗？

部分支持。

有托管的会话存储

AgentCore Memory 分两层：

• Short-term memory：按 session / actor 存原始交互事件，同步写入。负责"这一轮对话的即时上下文"。
• Long-term memory：异步提取，内置 Summary / Semantic / User Preferences 等策略，把跨会话的要点沉淀下来。

但历史不是自动捕获的

这是最容易踩的坑。开发者必须显式调用 API 去记录每一轮。用 Python SDK 举例，你需要在每轮对话中手动写入事件：

# 创建 memory 资源
response = agentcore_client.create_memory(
    name="chatbot-session",
    description="用户对话记忆"
)
memory_id = response["memoryId"]

# 每轮对话需手动创建事件
agentcore_client.create_event(
    memoryId=memory_id,
    actorId=user_id,
    sessionId=session_id,
    content={"role": "user", "text": "你好"}
)

agentcore_client.create_event(
    memoryId=memory_id,
    actorId=user_id,
    sessionId=session_id,
    content={"role": "assistant", "text": "你好！有什么可以帮你？"}
)

# 取回最近的对话历史
events = agentcore_client.list_events(memoryId=memory_id, sessionId=session_id)

# 取回长期记忆做上下文注水
long_term = agentcore_client.retrieve_memory_records(memoryId=memory_id)

官方博客的原话也确认了这一点：Short-term memory "stores them synchronously" 是在你调用了事件写入 API 之后才同步存；长期记忆的提取是在事件创建后异步触发的。换句话说，它不会在后台默默帮你录对话，是一个"托管存储 + 处理器"，不是"自动记录器"。

确保 context 不超模型上限：OOTB 吗？

不是自动的。这是最关键的结论。

AgentCore Memory 提供的 summarization，是把对话异步汇总进长期记忆 store（比如 Summary 策略会维护一份"该 session 的 running summary"）。但它是针对"已存储的事件"做摘要，不是对你发给 LLM 的那段实时 prompt 做自动压缩 / 截断。

举个具体例子：Claude 3.5 Sonnet 上下文 200K token，一个典型的多轮对话 20 轮后可能轻松到 30K+ token。AgentCore Memory 不会在 30K 时自动帮你压缩回 20K——你要自己判断何时截断、何时摘要。

官方博客在"Memory problem"一节也承认：在没有专门记忆系统的情况下，开发者过去得"手动 prune 或 summarize 早期对话"才能不超 token。AgentCore Memory 帮你省掉了自建记忆基础设施的麻烦，但context-window 的管理仍要你自己做——典型做法是：在每次调用模型前，取回相关的记忆（摘要 + 最近若干事件）来"按需注水"上下文，而不是等服务静默帮你截断。常见模式是：最近 N 轮原文 + 一句长期摘要 + 检索到的相关片段，拼成最终 prompt。

能力对照表

能力	AgentCore	Bedrock Agent（对比）	说明
会话持久化存储	✅ 托管	✅ 自动	AgentCore 需调 API 主动写入
自动录制对话历史	❌ 手动	✅ 自动	AgentCore 需手动 CreateEvent
跨 session 长期记忆	✅ 托管	✅ 内置	均为异步提取
自动防超 context 上限	❌ 手动	⚠️ 部分	AgentCore 需自己实现检索+注水/摘要
部署 / 扩缩 / 身份 / 可观测	✅ OOTB	✅ OOTB	平台核心能力

结论与建议

用 AgentCore 搭 chatbot：

• 会话管理有地基，但得自己接管线。你得在 agent 代码里规规矩矩地 CreateEvent 记录每一轮，再在需要时 ListEvents / RetrieveMemoryRecords 取回。
• "确保不超 context 上限"这一项不是它替你做的。要你在调用模型前自己加一层"记忆检索 + 摘要 / 截断"逻辑。

如果你想要更省心的 OOTB 会话 + 自动压缩，可以对比：

• Bedrock Agent（原生）：自带 orchestration 和自动 memory 管理，会话和上下文压缩由平台兜更多；
• 开源框架层（如 LangGraph）：提供 checkpoint / 持久化，但压缩逻辑同样要自己写；
• AgentCore：最灵活、运维最强，但"记忆与上下文"这层要你自己砌。

一句话：AgentCore 能搭 chatbot，而且生产级能力扎实，但别指望它把"会话管理"和"上下文不超限"当成免费午餐——地基是好的，房子得你自己盖。

本文链接：https://bookshadow.com/weblog/2026/08/01/aws-agentcore-chatbot-context-management/
请尊重作者的劳动成果，转载请注明出处！书影博客保留对文章的所有权利。