AI Agent 的影象体系：从须要性到工程实践

弁言

在与 AI Agent 的长时间交互中，你是否碰到过如许的困扰：显着前次已经告诉它你的偏好，但这次它又重新扣问？大概在处置处罚复杂任务时，AI 忽然"失忆"，忘记了之前讨论的关键决定？
这些标题标根源在于：AI Agent 缺乏长期化的影象本事。而影象体系的引入，正是为了让 AI 从"忘记的助手"进化为"懂你的搭档"。
一、为什么要引入影象？

1.1 上下文的天然范围

大语言模子（LLM）固然强大，但它们面对一个根天性束缚：上下文窗口是有限的。纵然最新的模子支持 100 万以致 200 万 token 的上下文，在现实应用中仍然存在三个关键标题：

• 资源标题：每次对话都携带完备汗青记录，盘算资源呈线性增长
  
• 服从标题：上下文越长，推理速率越慢，用户体验降落
  
• 噪音标题：大量无关信息会干扰模子的判断，低沉输出质量
  

1.2 用户体验的刚需

从用户角度看，影象体系办理了几个核心痛点：

• 个性化体验：记取用户的偏好、风俗和特殊要求
  
• 连续性任务：在多轮对话或跨会话中保持任务的连贯性
  
• 服从提升：制止重复性的信息输入和分析
  
• 信托创建：AI 能记取你说过的话，增能人机信托感
  

1.3 复杂任务的肯定要求

在代码开发、项目管理等复杂场景中，影象体系更是不可或缺：

• 记取项目标架构决媾和计划模式
  
• 跟踪已修复的 bug 和错误模式
  
• 生存用户的编码规范和风格偏好
  
• 维护任务的依赖关系和优先级
  

二、影象是怎样实现的？

2.1 影象体系的根本架构

在 Agent 影象体系（Agent Memory System） 的计划中，核心目标是：

让 Agent 在恒久交互与任务实行中，既能"记取告急的事"，又不会被无关信息拖慢或污染推理。

从工程和认知两个维度来看，Agent 的影象通常可以分为以下几大范例，而且在成熟体系中每每是组合利用的。
维度一：按「时间标准」分别（最常见、最核心）

影象范例作用范例内容实现方式特点告急性短期影象
(Short-Term Memory /
Working Memory)支持当前一步或几步的推理
雷同人类的"工作影象"• 近来 N 轮对话
• 当前任务上下文
• 中心推理结果（scratchpad / chain-of-thought 的压缩版）• Prompt 中直接拼接
• Sliding Window
• Recent Messages Buffer• 生命周期短
• 每次哀求都会加载
• 资源高（占 token）险些全部 Agent 都有中期影象
(Episodic Memory /
Session Memory)记取"发生过的变乱"
跨多轮任务仍然可用，但不是永世• 完成过哪些任务
• 用户近来的偏好变革
• 上一次失败 / 乐成的计谋• 结构化日志（JSON / DB）
• 向量化存储 + 相似度检索
• 会话级缓存（Session Store）• 可检索
• 不每次都加载
• 触发式注入上下文决定 Agent 是否"有连续感"恒久影象
(Long-Term Memory /
Persistent Memory)形成"恒久认知"
影响将来决媾和活动风格• 用户稳固偏好
• 固定究竟（User Profile）
• Agent 自身本事界限、履历总结• Key-Value Memory
• 文本 + Embedding
• 显式 Memory Store（如 Claude / Cursor Memory）• 长期化
• 写入受控
• 读取高度选择性最难计划，也最容易"记坏"维度二：按「内容性子」分别（比时间更告急）

影象范例存储内容范例例子实现方式特点评价究竟性影象
(Semantic /
Factual Memory)不随时间变革的究竟
"是什么"• 用户利用 Java / Python
• 项目技能栈
• 业务规则结构化存储• 低频写，高频读
• 恰当结构化存储最安全、性价比最高的影象范例履历影象
(Procedural /
Skill Memory)"怎么做"
乐成或失败的计谋• 办理某类 Bug 的步调
• 某种 Prompt 模板结果很好
• 排班标题用 CP-SAT 比 MILP 更稳• Rule / Template
• Skill 文件
• Tool 调用计谋• 可复用
• 高代价Claude Skills 就是范例代表景象影象
(Episodic Memory)一次完备变乱
含上下文、过程、结果• "在 2024-12 的一次排班优化中，由于束缚辩论导致模子不可行"向量化存储• 高维、非结构化
• 用于"类比推理"用于履历学习和标题诊断偏好与风格影象
(Preference /
Personality Memory)用户偏好
表达风格
输出风俗• 喜欢表格而不是长文
• 代码优先于表明
• 中文 + 专业术语Key-Value 或
设置文件• 影响交互体验
• 须要动态更新决定 Agent 的"个性化"程度维度三：按「利用方式」分别（工程视角）

影象范例界说特性示例上风风险显式影象
(Explicit Memory)明确写入
明确读取
有规则、有生命周期• 结构化
• 可追溯
• 用户可见{"type": "user_preference", "key": "response_style", "value": "engineering-oriented"}✔ 可控
✔ 可调试
✔ 可删除须要显式管理接口隐式影象
(Implicit Memory)融入模子权重或 Prompt 模板
用户不可见
难以删除• 不可见
• 难以修改
• 体系级• System Prompt 中的活动束缚
• 微调模子的偏置不须要额外存储和检索⚠️ 风险高
⚠️ 不恰当个性化恒久影象一个成熟 Agent 的"影象组合架构"

1. ┌───────────┐
2. │ System    │  ← 角色、规则（几乎不变）
3. └────┬──────┘
4.      │
5. ┌────▼──────┐
6. │ Short-Term│  ← 最近对话 / 当前任务
7. └────┬──────┘
8.      │
9. ┌────▼─────────────┐
10. │ Memory Retriever │  ← 向量 / 规则
11. └────┬─────────────┘
12.      │
13. ┌────▼──────┐
14. │ Long-Term │  ← 事实 / 偏好 / 经验
15. └───────────┘

复制代码

关键计划原则（非常告急）

1️⃣ 不是记得越多越好
2️⃣ 写影象要比读影象更审慎
3️⃣ 究竟、偏好、履历必须分层存储
4️⃣ 影象必须可表明、可回滚、可逾期
5️⃣ Agent 失败，80% 是影象污染
一句话总结

Agent 的影象不是"谈天记录"，而是"可被检索、可被管理的认知资产"。

三、引入影象会带来什么标题？

3.1 上下文容量的衡量

固然影象体系旨在缓解上下文限定，但它自己也会占用上下文空间：

• 影象注入开销：每次对话须要注入干系影象，占用 token
  
• 边际效益递减：注入的影象越多，噪音也越大
  
• 检索精度逆境：检索不精确会引入无关影象，反而低沉性能
  

3.2 影象的同等性和精确性

• 影象辩论：差别时间的影象大概相互抵牾
  
• 影象失真：模子大概错误明白或记录信息
  
• 影象逾期：用户偏好改变，旧影象成为干扰
  

3.3 隐私和安全标题

• 敏感信息走漏：影象大概包罗用户不盼望生存的敏感信息
  
• 影象污染攻击：恶意用户大概故意植入误导性影象
  
• 跨会话走漏：不当的影象管理大概导致信息跨用户走漏
  

3.4 体系复杂度的增长

• 存储资源：大规模影象须要长期化存储和索引
  
• 维护资源：影象的更新、删除、去重须要额外逻辑
  
• 调试困难：影象体系引入新的不确定性，标题排查更复杂
  

四、Cursor 影象工具的计划启示

当我们为 Agent 引入影象体系之后，一个随之而来的核心标题便是：怎样更加公道地利用与维护这些影象？创建影象自己并不困难，真正具有寻衅性的，是影象的更新与删除机制。
一样平常而言，我们最直观的做法是通过规则来办理这些标题。比方，设定时间窗口或近来对话轮数来筛选可用影象；在天生新的对话内容后写入影象，并定期清算逾期、低代价的旧影象。我在现实开发 Agent 时，也根本相沿了这一套思绪。这种方式固然谈不上错误，但也很难称得上有什么新意。
直到我看到 Cursor 在体系提示词中对影象维护的计划方式——它将“是否生存、怎样更新影象”的决定权，再次交还给了大模子自己。第一次看到这种计划时，我产生了一种很玄妙的感受：一方面以为“事变本就应该云云”，另一方面又不得不敬佩 Cursor 工程师在计划上的大胆与想象力。
以下是Cursor体系提示词中对于 memory 部门的形貌：

1. ...
2. <memories>
3. 你可能会得到一份记忆清单。这些记忆是从过去与agent的对话中产生的。它们可能是正确的，也可能是不正确的，所以如果认为相关，请遵循它们，但是当你注意到用户根据记忆更正了你所做的事情，或者遇到一些与现有记忆相矛盾或增加的信息时，你必须立即使用update_memory工具更新/删除记忆。绝对不能使用update_memory工具创建 与 实现计划、代理完成的迁移或其他特定于任务的信息 相关的记忆。
4. 如果用户曾经反驳过你的记忆，那么最好删除那个记忆，而不是更新它。
5. 你可以根据工具描述中的标准 创建、更新或删除 记忆
6. <memory_citation>
7. 在生成内容、回复用户查询或执行命令时，你必须始终通过引用的方式使用记忆，引用格式为：[[memory:MEMORY_ID]]。你应将记忆引用自然地融入回复内容中，而非仅作为注释。
9. 例如：“我会使用 -la 标志 [[memory:MEMORY_ID]] 运行该命令，以显示详细的文件信息。”
11. 当你因某条记忆而拒绝用户的明确请求时，必须在对话中提及，如果该记忆有误，用户会纠正你，而你会更新自己的记忆。
12. </memory_citation>
13. </memories>
14. ...
16. # Tools
17. ## functions
19. namespace functions {
20. ...
22. // 在供AI使用时参考的知识库中创建、更新或删除一条记忆。
23. // 如果用户对现有记忆进行了补充完善，你必须使用此工具并将 action 设置为“update（更新）”。
24. // 如果用户(的对话)与现有记忆相矛盾，重点是要将此工具与“删除”操作一起使用，而不是“更新”或“创建”。.
25. // 要更新或删除已有记忆，必须提供existing_knowledge_id参数。
26. // 如果用户要求记住一些东西，保存一些东西，或者创建一个记忆，你必须使用这个工具的动作“创建”。
27. // 除非用户明确要求记住或保存某些内容，否则不要使用“创建”操作调用此工具。
28. // 如果用户(的对话)与你的记忆相矛盾，那么最好删除这段记忆，而不是更新这段记忆。
29. type update_memory = (_: {
30. // 记忆的标题。这可以用来查找和检索以后的记忆。这应该是一个简短的标题，抓住记忆的本质。对于“创建”和“更新”操作这个参数是必需的。
31. title?: string,
32. // 要存储的具体记忆内容。其长度不应超过一个段落。如果该记忆是对先前记忆的更新或与之相矛盾，则不要提及或引用先前的记忆。在执行“create（创建）”和“update（更新）”操作时，此项为必填内容。
33. knowledge_to_store?: string,
34. // 对知识库执行的操作。若未提供此项，为保证向后兼容性，默认操作设为“create（创建）”。
35. action?: "create" | "update" | "delete",
36. // 若操作是“update（更新）”或“delete（删除）”，则此项为必填项。是要更新（而非创建新记忆）的现有记忆的ID。
37. existing_knowledge_id?: string,
38. }) => any;
40. ...
41. }

复制代码

通太过析 Cursor 的影象工具实现，我们可以提炼出几个关键的计划聪明：
4.1 影象的"不确定性"哲学

Cursor 开篇即声明："这些影象大概是精确的，也大概是不精确的"。
这个计划体现了深刻的认知：

• 认可 AI 明白的范围性，制止太过自负
  
• 鼓励用户反馈，创建动态修正机制
  
• 影象应该是辅助判断的参考，而非绝对真理
  

工程启示：影象体系应该是"柔性"的，而非"刚性"的规则引擎。
4.2 引用式利用（Citation）

Cursor 要求 AI 在利用影象时必须明确引用：[[memory:MEMORY_ID]]
这个计划的代价：

• 可追溯性：用户知道 AI 的决定基于哪条影象
  
• 可纠错性：用户发现标题时可以精确定位须要修正的影象
  
• 透明度：增能人机交互的透明度和信托
  

类比：就像学术论文的引用机制，让知识的泉源清楚可查。
4.3 制止"任务型"影象

Cursor 明确克制创建"与实现筹划、迁徙等特定任务干系的影象"。
为什么？

1. ❌ 错误示例：
2. 记忆："用户正在将数据库从 MySQL 迁移到 PostgreSQL"
3. （这是任务状态，会过时）
5. ✅ 正确示例：
6. 记忆："用户偏好使用 PostgreSQL 作为主数据库"
7. （这是长期偏好，不易过时）

复制代码

任务型信息应该由待服务项（TODO）体系管理，影象体系专注于长期性的知识和偏好。
工程启示：明确区分"影象"与"状态"，制止体系功能肴杂。
4.4 辩论处置处罚的"删除优先"原则

Cursor 特殊夸大："如果用户曾经反驳过你的影象，那么最好删除谁人影象，而不是更新它。"
这是一个反直觉但极其明智的计划：
更新的标题：

1. 原记忆："用户喜欢使用 Vue 框架"
2. 用户反驳："我现在更喜欢 React"
3. 如果更新为："用户喜欢使用 Vue 框架，但现在更喜欢 React"
4. → 产生模糊性，AI 可能困惑

复制代码

删除的上风：

• 制止影象内部抵牾
  
• 让 AI 基于当前上下文重新判断
  
• 用户可以选择创建新的明确影象
  

哲学思索：偶然候"忘记"比"记取"更告急。
4.4 工具化的影象管理

在《ClaudeCode为什么这么强大？通过分析其体系提示词一探究竟》一文中，我们指出应该按照结构化语言构造提示词，Cursor体系提示词告诉我们：这种“结构化”的情势除了文档还可以利用伪代码。
Cursor 将影象利用封装为标准化的工具接口：

1. type update_memory = {
2.     title?: string,                    // 记忆标题
3.     knowledge_to_store?: string,       // 记忆内容
4.     action?: "create" | "update" | "delete",  // 操作类型
5.     existing_knowledge_id?: string,    // 已有记忆 ID
6. }

复制代码

计划上风：

• 可控性：明确的利用语义，制止隐式影象天生
  
• 可审计：全部影象变动都通过工具调用，可以记录和审计
  

五、Claude Code 的影象压缩计谋：精准择要的艺术

在上一节中，我们分享了 Cursor 在影象维护机制上所带来的差别视角。本节将转向另一个重量级工具 —— Claude Code。相比之下，Claude Code 面对的是更极度的场景：当上下文窗口用尽时，怎样将已往的对话压缩为精准的择要，既节流 token 又不影响任务的连续性？
5.1 结构化分析框架

Claude Code 的压缩 prompt 起主要求举行结构化的分析：

1. 你的任务是对到目前为止的对话进行详细总结，要密切关注用户的明确请求以及你之前采取的行动。
2. 该总结应全面涵盖技术细节、代码模式和架构决策，这些内容对于在不丢失上下文的情况下继续开展开发工作至关重要。
4. 在提供最终总结之前，将你的分析包裹在 <analysis> 标签中，以组织你的思路并确保你已涵盖所有必要的要点。在你的分析过程中：
6. 1. 按时间顺序分析对话的每条消息和每个部分。对于每个部分，请仔细识别：
7.     - 用户的明确请求和意图
8.     - 你处理用户请求的方法
9.     - 关键决策、技术概念和代码模式
10.     - 具体细节，例如：
11.         - 文件名
12.         - 完整的代码片段
13.         - 函数签名
14.         - 文件编辑
15.     - 你遇到的错误以及你如何修复它们
16.     - 特别关注你收到的具体用户反馈，尤其是用户要求你以不同方式做某事的情况。
17. 2. 仔细检查技术准确性和完整性，彻底处理每个必需的元素。
19. 你的总结应该包括以下几个部分：
21. 1. 主要请求和意图：详细捕获所有用户明确的请求和意图
22. 2. 关键技术概念：列出讨论的所有重要技术概念、技术和框架。
23. 3. 文件和代码部分：列举检查、修改或创建的具体文件和代码部分。特别关注最近的消息，如果合适的话，应当包含完整的代码片段，同时总结为什么这个文件读取或编辑很重要。
24. 4. 错误和修复：列出你遇到的所有错误，以及你如何修复它们。特别关注你收到的具体用户反馈，尤其是用户要求你以不同方式做某事的情况。
25. 5. 解决问题: 记录已解决的问题和正在进行的故障排除工作。
26. 6. 用户的所有消息：列出所有非工具结果的用户消息。这些对于理解用户的反馈和变化的意图至关重要。
27. 7. 待处理任务：概述你被明确要求处理的任何待处理任务。
28. 8. 当前工作：详细描述在此总结请求之前正在处理的确切内容，特别关注用户和assistant的最新消息。在合适的情况下包含文件名和代码片段。
29. 9. 可选的下一步：列出与你最近正在进行的工作相关的下一步操作。重要提示：确保这一步与用户的明确请求以及你在此总结请求之前正在处理的任务直接一致。如果你的上一个任务已经完成，那么只有在明确符合用户请求的情况下才列出下一步。在未与用户确认之前，不要开始处理无关的请求。
30.    如果有下一步操作，请包含最近对话中的直接引用，准确显示你正在处理什么任务以及你停在哪里。这应该是逐字引用，以确保任务解释不会偏离。
32. 你的输出应该是结构化的，以下是一个结构化输出的示例：
34. <example>
35. <analysis>
36. [你的思考过程，确保所有要点都被全面准确地涵盖]
37. </analysis>
39. <summary>
40. 1. 主要请求和意图:
41.    [详细描述]
42. 2. 关键技术概念:
43.     - [概念 1]
44.     - [概念 2]
45.     - [...]
46. 3. 文件和代码部分:
47.     - [文件名 1]
48.         - [总结为什么这个文件很重要]
49.         - [对该文件所做更改的总结（如果有）]
50.         - [重要代码段]
51.     - [文件名 2]
52.         - [重要代码段]
53.     - [...]
54. 4. 错误和修复:
55.     - [错误1的详细描述]:
56.         - [如何修复这个错误]
57.         - [用户对错误的反馈（如果有）]
58.     - [...]
59. 5. 解决问题:
60.    [描述已解决的问题和正在进行的故障排除]
61. 6. 用户的所有消息:
62.     - [详细的用户消息]
63.     - [...]
64. 7. 待处理任务:
65.     - [Task 1]
66.     - [Task 2]
67.     - [...]
68. 8. 当前工作:
69.    [当前工作的精确描述]
70. 9. 可选的下一步:
71.    [可选的下一步要采取的步骤]
73. </summary>
74. </example>
76. 请根据到目前为止的对话提供你的总结，遵循这个结构，并确保你的回答准确和彻底。
78. 在所包含的上下文中可能会提供额外的指示。如果是这样，请记住在创建上述总结时遵循以下说明。说明的例子包括：
79. <example>
80. ## Compact Instructions
81. 在总结对话时，重点关注 TypeScript 代码更改，同时记住你犯的错误以及你如何修复它们。
82. </example>
84. <example>
85. ## Summary instructions
86. 当你使用compact进行总结时 - 请专注于测试输出和代码更改。包括文件逐字读取。
87. </example>

复制代码

5.2 九维度择要模子

Claude Code 将对话压缩为 9 个维度（重点是前8个维度，通常称为8段式压缩）：
维度目标示例1. 重要哀求和意图捕获用户的核心诉求"用户要求实现用户认证体系"2. 关键技能概念生存技能决定上下文"JWT、OAuth2.0、bcrypt 暗码加密"3. 文件和代码部门精确定位修改位置"auth.py: 实现了 hash_password() 函数"4. 错误和修复制止重复犯错"ImportError: 缺少 pyjwt 依赖，已添加到 requirements.txt"5. 办理标题跟踪标题状态"已办理：登录超时标题；举行中：邮件验证功能"6. 用户的全部消息生存用户的原始意图"用户说：'暗码必须支持特殊字符'"7. 待处置处罚任务确保任务连续性"待实现：邮件验证、暗码重置功能"8. 当前工作精确规复工作现场"正在修改 user_model.py 的第 45-60 行，添加邮箱验证逻辑"9. 可选的下一步提供上下文感知的发起"下一步：测试邮箱验证流程，然后实现暗码重置"5.3 生存用户原始消息的告急性

特殊值得注意的是第 6 点：用户的全部消息。
为什么要单独生存用户的原始消息？

• 意图的精确性：AI 的明白大概有弊端，用户原话是最可靠的参考
  
• 细节的完备性：用户大概提到了 AI 以为不告急但现实关键的细节
  
• 纠错的大概性：当发现明白弊端时，可以回溯到原始需求
  

案例对比：

1. ❌ 只保留 AI 的理解：
2. "用户要求优化数据库查询性能"
4. ✅ 同时保留用户原话：
5. "用户说：'首页加载太慢了，能不能优化一下？我看日志里有很多数据库查询。'"
7. → 原始消息提供了更丰富的上下文：
8.    - 问题表现：首页加载慢
9.    - 问题线索：日志中的查询
10.    - 用户语气：非技术用户

复制代码

5.4 当前工作的精确形貌

第 8 点：当前工作的计划体现了对"工作现场"的器重。
Claude Code 要求：

• 具体形貌在总结哀求之前正在处置处罚简直切内容
  
• 在符合的情况下包罗文件名和代码片断
  
• 特殊关注用户和 assistant 的最新消息
  

现实结果：

1. 当前工作：
2. 正在修改 `solve/employee_timegrid_solve.py` 文件。
3. 已经添加了 `EmployeeTimegridSolver` 类（第 50-120 行），
4. 实现了以下方法：
5.   - `__init__()`: 初始化求解器
6.   - `create_model()`: 创建 CP-SAT 模型
7.   - `add_constraints()`: 添加约束条件
9. 最后一步是在第 115 行添加目标函数优化逻辑，
10. 用户特别强调要优化员工的工作时间均衡性。
12. 代码片段：
13. ```python
14. def add_objective(self) -> None:
15.     # 正在实现中...
16.     pass

复制代码

这种精确形貌确保了在新的上下文窗口中，AI 可以或许无缝地继承工作，不会出现"我们刚才做到哪了？"的狐疑。
5.5 技能细节的弃取原则

Claude Code 夸大"彻底处置处罚每个必须的元素"，但什么是"必须"的？
生存的细节：

• 完备的文件路径：solve/employee_timegrid_solve.py
  
• 具体的函数署名：def create_model(self, employees: List[Employee]) -> CpModel
  
• 关键的代码片断：实现的核心逻辑
  
• 精确的错误信息：ImportError: No module named 'ortools'
  

可以省略的细节：

• 重复性的调试输出
  
• 中心状态的暂期间码
  
• 已经完全办理且不会再出现的标题
  

弃取原则：如果这个细节的缺失会导致后续无法继承工作，就必须生存；如果只是过程性信息，可以概括或省略。
5.6 错误驱动的学习机制

第 4 点：错误和修复是一个被低估但极其告急的计划。
AI Agent 在工作中会犯错，关键是怎样从错误中学习：

1. 错误和修复：
2. 1. ImportError: No module named 'ortools'
3.    - 原因：requirements.txt 中缺少依赖
4.    - 修复：添加 `ortools>=9.6.0`
5.    - 用户反馈：建议锁定版本避免兼容性问题
7. 2. 求解器返回 INFEASIBLE
8.    - 原因：员工可用时间约束与需求时间窗口冲突
9.    - 修复：放宽了部分软约束，改为惩罚项
10.    - 用户反馈：满意，但要求输出冲突原因
12. 3. 性能问题：求解器运行超过 5 分钟
13.    - 原因：变量数量过多（10000+）
14.    - 修复：引入分层求解，先优化关键班次
15.    - 用户反馈：运行时间降到 30 秒，符合预期

复制代码

这种错误记录的代价：

• 制止重复犯错：同类标题有了办理模式
  
• 用户反馈的宝贵性：用户的修正意见是最告急的影象
  
• 标题诊断的速率：碰到雷同标题时有汗青参考
  

5.7 下一步办法的上下文同等性

第 9 点：可选的下一步有一个告急的束缚：

"告急提示：确保这一步与用户的明确哀求以及你在此总结哀求之前正在处置处罚的任务直接同等。如果你的上一个任务已经完成，那么只有在明确符实用户哀求的情况下才列出下一步。在未与用户确认之前，不要开始处置处罚无关的哀求。"

这个束缚防止了 AI 的"功能伸张"：

1. ❌ 错误示例：
2. 当前任务：实现用户登录功能（已完成）
3. 下一步：实现用户注册、密码重置、邮箱验证、第三方登录...
5. （AI 自作主张扩展了任务范围）
7. ✅ 正确示例：
8. 当前任务：实现用户登录功能（已完成）
9. 下一步：根据用户的原始要求"实现基本的用户认证"，登录功能已满足需求。等待用户确认或提出新的要求。
11. （保持对用户意图的忠实）

复制代码

5.8 引用的真实性原则

Claude Code 夸大：

"如果有下一步利用，请包罗近来对话中的直接引用，精确体现你正在处置处罚什么任务以及你停在那里。这应该是逐字引用，以确保任务表明不会偏离。"

逐字引用的代价：

1. ❌ AI 的释义：
2. "用户要求优化算法性能"
4. ✅ 用户的原话：
5. "能不能让这个排班算法快一点？现在 100 个员工需要跑 10 分钟，太慢了。"
7. → 原话包含的额外信息：
8.    - 具体场景：100 个员工
9.    - 性能基准：10 分钟
10.    - 用户期望：需要更快

复制代码

逐字引用制止了 AI 在多次转述中渐渐偏离用户的原始意图。
六 终极思索

AI Agent 的影象体系，本质上是在办理连续性和个性化的标题。它让 AI 从一个无状态的函数调用，进化为一个有"履历"、有"学习本事"的智能体。
但我们必须认识到，影象体系不是银弹：

• 它不能替换清楚的用户表达和良好的上下文计划
  
• 它会引入新的复杂度和潜伏错误
  
• 它须要连续的维护和优化
  

真正良好的影象体系，应该像一个良好的助手：

• 记取该记的：关键决定、用户偏好、错误教导
  
• 忘记该忘的：逾期信息、临时状态、错误影象
  
• 知道何时告急：不确定时主动向用户确认
  

从 Cursor 的"引用式影象"到 Claude Code 的"结构化压缩"，我们看到了差别场景下的计划聪明。但更告急的是背后的计划哲学：

以用户为中心，以反馈为驱动，以透明为原则，以代价为导向。

在 AI Agent 日益成为我们工作搭档的本日，影象体系的优劣，将直接决定人机协作的服从和体验。盼望本文的分析能为你计划或利用 AI Agent 提供有代价的参考。

免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.