11|会话管理:Session 物理隔离与 Working Memory 的底层实现
Tony Bai

你好,我是 Tony Bai。欢迎来到《从 0 开始构建 Agent Harness》专栏的第十一讲。
在上一讲中,我们通过 PromptComposer(动态提示词组装器)让 Agent 拥有了阅读项目专属规范(AGENTS.md)和外挂技能(Skills)的能力。Agent 不再是一个“没有背景故事”的孤儿,而是能够瞬间化身为遵守团队纪律、拥有团队技能的高级工程师。
到目前为止,我们在 main.go 中测试 Agent 都是采用“单次运行(One-shot Execution)”的模式。
这意味着,每当我们执行 go run cmd/claw/main.go 时,Agent 都会从头开始。然而,在工业级的 Harness 驾驭工程中,Agent 面临的入口场景是极其复杂多样的:
Console 场景:在终端启动时,Harness 通常会以当前目录(WorkDir)为单位,建立一个默认的 Main Session。
飞书 / 微信 / Slack 场景:如果 Agent 作为一个服务端运行,它可能会同时接收来自“飞书研发群 A”“飞书运维群 B”以及“微信用户 C”的指令。
试想一下:群 A 的人在让 Agent 重构 main.go,而群 B 的人同时让 Agent 查服务器日志。如果我们只有一个全局的 contextHistory 切片,这两个完全不相干的任务指令和文件内容就会混杂在一起发给大模型。大模型瞬间就会精神分裂。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始构建 Agent Harness》,新⼈⾸单¥59
《从 0 开始构建 Agent Harness》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论