Southblock'Blog

✅什么是Loop Engineering  Loop Engineering 这个词在2026年6月由 OpenClaw 创始人 Peter Steinberger 和 Claude Code 负责人 Boris Cherny 几乎同时提出。 Peter 的原话是：”You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny 则说：”My job is to write loops.”  随后 Google 工程师 Addy Osmani 在6月7日发了一篇博客正式系统化了这个概念（https://addyosmani.com/blog/loop-engineering/ ）  Addy 一句话定义最常被引用： “Loop engineering is replacing yourself as the person who prompts the agent. You design the sys ...

✅如何实现Harness Engineering 在 Agent 开发领域，Harness Engineering 的体系通常由六大核心要素（或组件）构成。这六个要素共同搭建起了让 AI 能够安全、稳定、长期干活的“操作系统”。  上下文管理 前面我们说过了，Harness Engineering是包含了Context Engineering的，所以，Context也必然是Harness中至关重要的一部分。  通过上下文工程来做上下文管理，让AI只看到恰到好处的上下文信息。  这里面包括长期、短期记忆，包括Skill，包括记忆压缩等等上下文优化的相关技术。  比如： 动态投喂：当 AI 在写前端代码时，系统会自动把相关的 UI 组件库文档、CSS 规范注入给它；当它在写后端接口时，又会自动切换成数据库 Schema 和 API 契约。 防过载与压缩：AI 的“短期记忆”（上下文窗口）是有限的。优秀的上下文工程会在信息过多时，自动对旧对话进行摘要压缩，或者把不常用的规范移出当前窗口，防止 AI 因为信息过载而“变笨”或产生幻觉。 目录化指引：它不会把几万字的员工手册一次 ...

✅以AI Coding为例说明Harness Engineering 结合程序员日常的 AI Coding 场景，这三者的区别会变得非常具体和生动。我们可以把 AI 想象成你的一个“AI 结对编程伙伴”，来看看这三种工程手段分别是如何驱动它的：  Prompt Engineering：怎么给 AI 下达“单次指令” 这就像你给身边的同事口头布置一个具体的小任务。你的指令越清晰，他干活越利索。 日常表现： 你在 IDE 的 AI 聊天框里输入：“帮我用 Python 写一个快速排序算法，要求加上详细的中文注释。” 或者：“这段代码报错了，帮我分析一下原因并给出修复建议。” 核心动作：你通过角色扮演（“你是一个资深架构师”）、明确约束（“不要用递归实现”）、指定格式（“输出 Markdown 格式”）来引导 AI 生成你想要的代码片段。 局限：如果你只靠 Prompt，AI 就像一个刚入职、对你项目一无所知的新人。他写出来的代码可能语法完美，但变量命名风格跟你团队完全不符，甚至重复造了你项目里已经存在的轮子。  Context Engineering：给 AI 投喂“ ...

✅什么是Harness Engineering？ Harness Engineering（驾驭工程）是随着AI Agent技术爆发而诞生的一个全新技术方案。  之前我们讲过提示词工程和上下文工程。分别是Prompt Engineering和Context Engineering，那么到底发生了什么？又要出现一个新的Harness Engineering呢？  不管是提示词工程也好、上下文工程也好，他们在约束和改变的都是LLM能看见什么。说白了就是期望通过调整LLM能看见的东西让Agent的输出结果更好、更稳定。  但是实际上，很多人发现，即使换了最好的模型、调了成百上千次提示词、做了无数种上下文火优化的手段，但是还是无法保证Agent的输出结果的稳定性。总是时好时坏的。  这时候人们发现，也许再调节和LLM交互相关的内容已经达到瓶颈了，需要在LLM之外做优化。这些可优化的内容包括任务如何拆分与编排、如何设计运行时状态与状态流转、如何让模型可以自检测与恢复。也就是说，把Agent比喻成一匹马，你不仅要告诉他去哪，怎么去，还需要有一套马鞍来驾驭它去往正确的方向。    所 ...

✅Spring AI Alibaba接入Mem0做长期记忆在讲Spring AI如何接入mem0之前，先介绍一个Mem0的REST Api Server。 REST Api Server Mem0 的 REST API Server 是其核心组件之一，提供了标准化的 HTTP 接口，方便开发者将 Mem0 集成到各种应用中，而无需直接操作底层向量数据库或记忆逻辑。  有了它之后，我们可以通过HTTP接口的方式访问本地的mem0的python代码。这样代码中就可以更好的集成他来做长期记忆了，如：  123curl -X POST http://localhost:8000/memories \-H "Content-Type: application/json" \-d '{ "messages": [ {"role": "user", "content": "I im a JAVA programmer."} ...

✅Mem0的实现原理 其实Mem0它并不是个存储，他只是一个框架，是一个协调了LLM+向量数据库+embedding模型+图数据库+sqlLite数据库的一个组件。  LLM：负责记忆提取和自然语言理解 向量数据库：用于高效语义检索，将对话中提取的关键信息嵌入为高维向量。 Embedding模型_：_用于将记忆内容做向量化嵌入 图数据库（可选）：用于追踪实体之间的关系（如“爱丽丝的朋友是约翰”），支持复杂的情境推理。 sqlLite数据库（内置）：本地存储记忆历史  这里面，除了sqlLite在Mem0中内置了一个以外，其他的都需要单独提供。比如上面的示例中我们单独部署了一个向量数据库，在代码中引入了对话模型和embedding模型。  Mem0 的记忆生命周期包括两个核心操作：添加（add） 和 检索（search）。  添加记忆（add） 信息提取：利用 LLM（如 DeepSeek、GPT）从对话中自动识别关键事实（如“我喜欢Coding”）。 冲突检测与合并：新记忆与已有记忆比对，自动处理矛盾（如先说“喜欢Coding”，后说“讨厌写代码”）。 结 ...

✅长期记忆实现方案——Mem0提到长期记忆，不得不提的一个框架就是——Mem0(https://github.com/mem0ai/mem0 )，这是一个开源项目，旨在为 AI Agent提供个性化、可持久化的长期记忆能力。它通过将用户与 AI 的交互历史进行结构化存储、向量化，并结合检索增强生成（RAG）机制，使 AI 能够“记住”过去与特定用户的对话内容、偏好、上下文等信息，从而在后续交互中提供更连贯、个性化的响应。  Mem0 的实现主要基于以下几个关键技术模块： 记忆提取 在每次用户与 AI 交互后，Mem0 使用一个记忆提取器分析对话内容。 提取关键事实、偏好、意图等，例如：“用户喜欢喝无糖咖啡”、“用户住在杭州”。 这些信息被转化为简洁、结构化的记忆条目。  向量化与存储 每条记忆被嵌入成向量 向量存储在向量数据库中，并关联到特定用户 ID。 支持元数据（如时间戳、来源对话 ID）以便后续过滤或排序。  记忆检索 在新对话开始时，Mem0 根据当前用户输入查询向量数据库。 通过相似度搜索召回最相关的过往记忆。 可结合时间衰减、相关性评分等策略 ...

✅什么是长期记忆 前面我们讲过，Agent的记忆能力必不可少。Agent 的“记忆”是指其在与环境或用户交互过程中，用于存储、检索和利用信息的机制。这些信息可以包括：  用户的历史对话 工具调用结果 任务执行状态 环境感知数据 学到的知识或经验  没有记忆的 Agent 只能处理孤立的请求，无法实现上下文感知、个性化服务或持续改进。  之前我们在介绍Memory的时候，讲的都是短期记忆，短期记忆是指 Agent 在当前会话或任务周期内临时保存的信息，通常以上下文窗口（context window）的形式存在。  而且，前面我们也介绍过原理，不管是spring ai还是langchain4j等框架，他们都是自己在内存维护（或者做了持久化）的记忆，然后把这些记忆当做上下文的方式直接传给LLM的。  但是不管怎么样维护记忆内容，最终大模型想要实现记忆，都需要通过messages把历史的所有对话传过去。而由于LLM的token限制，他只能输入一定长度的对话记录，又因为大模型其实本身的注意力机制的限制，token太长也会导致他会忽略掉某些关键信息。  所以，短期记忆 ...

✅实战：Manus的上下文工程实践 Manus 曾经发表过一篇文章《Context Engineering for AI Agents: Lessons from Building Manus》，里面介绍了一下他们在上下文工程方面的实践。  这篇文章我反反复复看过好几次，最开始看的时候会不得要领，慢慢会觉得确实写得好。我试着总结下。  Manus 在构建其 AI Agent过程中，选择了一条“上下文工程”的路径，而非训练端到端模型。这一决策基于对快速迭代、成本效率和与底层大模型解耦的综合考量。以下是 Manus 上下文工程实践的核心要点总结：  围绕 KV 缓存进行设计 在 Transformer 架构中，自注意力机制（Self-Attention）需要为每个 token 计算与其他所有 token 的注意力权重。具体来说，对于输入序列中的每个 token，模型会生成三个向量：  **Query (Q)**：当前 token 的查询向量 **Key (K)**：其他 token 的键向量 **Value (V)**：其他 token 的值向量  在自回归生成（即 ...

✅什么是上下文工程？前面我们介绍过了，过长的上下文，会带来幻觉、token爆炸、超出上下文窗口限制、不稳定、效果差、性能差等问题。这些问题，通过传统的提示词工程已经无法解决了。（哈哈哈，提示词工程都变成传统手艺了），因为上下文不仅仅包括提示词。  于是，针对整个上下文做优化的上下文工程就应运而生了。提示词工程是关注和大模型说什么，上下文工程是关注让大模型看到什么。    还记得我们在RAG的时候提到过的：Garbage in ，Garbage out么？上下文工程其实也是在不断地优化上下文，让智能体（LLM）只看到恰到好处的上下文信息。  大语言模型（LLM）像一种新型操作系统，而它的上下文窗口就是 RAM（工作内存）。上下文工程，就相当于操作系统的内存管理器——决定哪些数据该加载进 RAM，哪些该移除或压缩。  LangChain在2025年7月发布了一篇文章《Context Engineering for Agents》，从Agent开发的角度来看，为了让Agent的上下文恰到好处，文章将上下文工程方法归纳为四个过程：Write（写入）、Select（选择）、Comp ...