Learn and share.
最近在做 Agent 相关开发时，发现一个很有意思的现象：同样是上下文压缩，在不同业务场景下的影响天差地别。
用 Claude Code、Codex、Cursor、Trae这类编程工具写代码，对话压缩个两三次，你就会明显感觉到它 “变笨了”—— 找不到工具、记不住文件路径、忘记之前定好的约束，甚至开始重复做已经完成的事。而日常聊天类产品，比如你跟豆包聊一下午，天南海北扯几十轮，上下文不知道被压缩了多少轮，你却几乎感觉不到明显的质量下降。
这背后不是模型能力的差距，而是两类业务对上下文信息的要求，本质上就不在一个维度上。
根据《进程级Agent沙箱的12道安全防线》，对主流操作系统的12个管控维度，推荐了轻量级落地方案，供大家参考。
在AI Agent从“聊天助手”向“自主执行者”演进的今天，我们正面临着前所未有的安全挑战。当Agent开始拥有访问文件系统、调用命令行工具甚至发起网络请求的能力时，一个失控的Prompt就可能让整个服务器沦陷。
为了让Agent既能“放手干活”，又不“惹是生非”，进程级沙箱（Process-level Sandboxing）成为了保障宿主环境安全的最后一道防线。
最近AI Agent技术火热，大家都很感兴趣，不少同学都已开始实践。在落地的过程中，有一对矛盾始终绕不开：
1、必须给Agent赋能和赋权，否则Agent就没有行动力
2、必须管控好Agent，防止Agent一抽风就把电脑炸了
对于问题1，我们有harness、tools、skills、MCP、sub-agent等等
对于问题2，就要用到沙箱技术了
市面上的沙箱技术五花八门，各有千秋。今天咱们就浅聊一下Agent场景下，常见的几类沙箱技术方案。
如果你是大模型API的重度用户，看着token快速燃烧，大概率会思考过这样一个问题：
每次和大模型对话，都会先有几百个token的固定system prompt（角色设定、工具定义、甚至是一整份文档），然后才是几十个token用户的问题。但我们却要为这段固定不变的system prompt反复付费、反复等它算完。这是一种巨大的浪费，不能想想办法节约一些token吗？
Prompt KV Cache要解决的就是这件事：让完全相同的prompt前缀不要重复计算，可以在后续的对话中，继续复用已经计算好的结果。本文来剖析一下，这个技术是如何实现的。
不得不佩服咱们IT大佬起名字的能力（发明新概念，好像一直是IT圈的执念），由于多位技术大佬的追捧，最近Loop Engineering的概念又突然火爆起来。
简单来说，Loop Engineering的核心理念就是：不要再一轮一轮地手动给AI Agent写提示词了，而是去设计一个自动化循环系统，让AI在这个系统中自主执行、验证和迭代，直到完成目标。
在过去（比如前几个月），大家用AI的方式为“人机乒乓模式”的大循环：
任务开始，人类告诉Agent要做什么 ->
Agent推进任务 -> 人类判断结果，决定方向，告诉Agent要做什么 ->
Agent推进任务 -> 人类判断结果，决定方向，告诉Agent要做什么 ->
......
Agent推进任务 -> 人类判断任务结束
如果说大模型是AI Agent的大脑」，那么工具调用系统就是 Agent 的「双手」。没有工具的Agent，就像一个被关小黑屋的聪明人，空有一堆想法却无法落地。今天咱们基于nanobot开源项目的源码分析，深入解析AI Agent的四种主流工具调用机制。
Continue reading AI Agent是如何使用工具的：Tools、MCP、CLI、Skills四种机制深度解析
在大模型应用开发中，我们常常过度关注Prompt编写和模型效果，却忽略了一个更底层的问题：Skill（工具/能力）应该在什么时候、以什么方式被触发？
一个成熟的 AI Agent 系统，绝不应该把所有压力都交给 LLM 去“猜”。如果触发机制设计不好，要么上下文爆炸导致成本失控，要么意图误判导致用户体验灾难。
本文将系统性拆解Skill触发的完整生命周期，从事件源头到执行管控，为你提供一套可落地的架构设计参考。
一、左右耳机是如何配对的
一直以来，我都以为FreeBuds的左右耳是唯一绑定的。有一次听到一个音频节目，了解到闲鱼上有售卖单个耳机的商家，这才发现，同型号、同固件版本的FreeBuds是可以重新绑定配对的。
