小红书 AI Agent开发一面(暑期)

1. 自我介绍

2. 介绍下项目，重点讲架构、关键设计和线上问题

3. Agent 的上下文窗口不够时，长短期记忆应该怎么分层设计

长短期记忆不能简单理解成“最近消息”和“很久以前的消息”。更合理的设计是把状态拆成三层：工作记忆负责当前回合执行所需的最小上下文，摘要记忆负责阶段性中间结论，长期记忆负责稳定事实、偏好、任务状态和关键证据索引。这样做的好处是短链路推理不会被旧噪声拖死，而长任务又能在需要时按状态检索历史事实。

真正难的不是分层本身，而是写入和召回策略。不是每条消息都值得进长期记忆，通常只把高价值、可复用、低歧义的信息写进去，比如用户偏好、外部工具执行结果、关键约束、任务完成状态。否则记忆库会迅速变成垃圾堆。

4. Agent 里的长期记忆为什么不能只靠向量库

向量库适合做语义近邻召回，但长期记忆里很多信息不是“语义相似”问题，而是“状态一致性”问题。比如用户偏好、任务是否完成、某个文件是否已经修改、某个工单是否已关闭，这些更像结构化状态而不是自然语言片段。如果全靠向量召回，容易出现旧状态覆盖新状态、相似事实互相污染、时间顺序丢失的问题。

所以长期记忆通常至少要做混合存储：文本片段进向量库，稳定键值事实进 KV 或文档库，事件轨迹进 append-only log，必要时再配一层图结构表示实体关系。记忆系统本质是状态系统，不是大号聊天记录。

5. 本地记忆存储怎么设计，才能兼顾速度、可恢复和可调试

本地记忆最怕两件事：一是写得快但恢复不了，二是能恢复但查不清是谁写进去的。比较稳的方案是 WAL 日志 + 结构化快照 + 二级索引。写入时先记事件日志，再异步刷到结构化存储；恢复时优先加载快照，再回放日志；调试时可以按会话、任务、时间戳和写入来源回放。这样既能保留执行轨迹，也能支持断点恢复。

class MemoryEvent:
    def __init__(self, ts, session_id, kind, payload):
        self.ts = ts
        self.session_id = session_id
        self.kind = kind
        self.payload = payload

class MemoryStore:
    def __init__(self):
        self.snapshot = {}
        self.wal = []

    def append(self, event: MemoryEvent):
        self.wal.append(event)
        self.snapshot.setdefault(event.session_id, []).append(
            {"kind": event.kind, "payload": event.payload}
        )

    def replay(self, session_id):
        return [e for e in self.wal if e.session_id == session_id]

6. 什么是 SDD，为什么它适合复杂 Agent 系统

SDD 可以理解成一种 Spec / Schema Driven Development 思路，本质是先把任务输入、输出、状态约束、工具协议、错误语义和验收标准显式定义，再让 Prompt、执行器、评测和日志围绕这个规范运行。它适合 Agent 的原因在于 Agent 天生多环节、多状态、多失败模式，如果没有统一规范，系统会很快变成一堆 prompt 和脚本拼接物。

SDD 最大的价值不是“写文档”，而是把不可控的自然语言流程压缩成部分可验证的执行结构。这样工具参数能校验，状态迁移能检查，异常能分类，评测也能挂到明确接口上。对多 Agent 系统来说，没有 spec，后面几乎一定失控。

7. OpenSpec 的设计思路是什么，核心优缺点在哪

OpenSpec 这类思路的核心是把任务目标、角色边界、工具协议、约束条件、输出格式和中间状态显式化，让模型不再完全依赖隐式 prompt 理解任务。优点很直接：可观测、可测试、可扩展、可替换模型，而且更适合团队协作。缺点也很明显：前期抽象成本高，规格写得差时反而比自由 prompt 更僵，面对开放任务时需要不断扩展 schema。

如果从系统角度讲，它的真正难点不在格式设计，而在版本演化。spec 一旦变更，工具层、执行层、评测层和历史数据兼容性都会跟着变，所以它更像系统工程，不只是提示词工程。

8. Prompt 工程的结构应该怎么设计，才不至于越写越乱

Prompt 最怕“所有规则都往 system prompt 里堆”。比较稳的设计是分层：系统层写角色和不可违背规则，任务层写目标与流程，工具层写协议和参数要求，示例层写边界案例，状态层写当前上下文与中间结果。这样每层职责单一，调试时也知道改哪一块，而不是几千字 prompt 里盲改。

真正成熟的 Prompt 工程通常还会做模板变量化、版本管理、A/B 实验、失败归因和回滚。也就是说，Prompt 不是一段文案，而是配置系统的一部分。

9. 常见 Agent 范式有哪些，分别适合什么任务

常见范式大概可以分成 ReAct、Plan-Execute、Reflect、Toolformer 式调用、Router-Worker、多 Agent 协作和状态机驱动执行。ReAct 适合中等复杂度、依赖观察反馈的任务；Plan-Execute 更适合长链任务，把规划和执行拆开能减少局部贪心；Reflect 适合需要自检和修复的任务；Router-Worker 适合多类任务路由；状态机驱动则更适合高约束业务，因为每一步更可控。

真正工程落地时，很少纯用一种范式，通常是规划层一种，执行层一种，恢复层再叠一层。范式不是信仰问题，核心是任务形态和失败代价。