AI拉呱-洞察AI前沿

5分钟掌握Agentic AI工作流这是智能体的时代 AI拉呱：洞察AI技术前沿 📷 （图：AI拉呱）在2026年，一个残酷的事实是——**"与数据对话的应用"**已不再被视为重大创新。过去几年里，我见过无数文本输入、文本输出的应用。说实话，这些应用确实很适合学习，但时代已经变了。我们必须进化自己，跟上潮流。也许了解这一点后，你决定迈出下一步——添加向量数据库，构建可靠的RAG（检索增强生成）管线。这很棒，但事实是它仍然只是一个花哨的聊天机器人。我们需要更进一步，超越花哨的聊天机器人。最近我意识到，现实世界的问题不需要对话伙伴，它们需要的是行动者。它们需要能够接受高层目标、分解成逻辑步骤、决定使用哪些工具并实际执行任务的系统。关键在于，我们不必手动硬编码每一个条件。系统足够智能，可以自行采取必要步骤来实现目标。没错，这就是聊天机器人和Agentic AI工作流的区别。聊天机器人等待指令。智能体自己想办法完成任务。如果你希望构建真正可扩展且能提供巨大价值的系统，你需要理解自主性。好消息是——它绝对没有听起来那么复杂。给我五分钟，我会详细拆解这些智能体工作流的原理。我还会帮助你理解为什么它们正在取代传统方法，以及你今天如何开始构建第一个自主循环。智能体公式 📷 （图：AI拉呱）要构建真正在现实世界中工作的系统，我们首先需要理解什么是智能体。AI智能体是由特定的、确定性的架构循环驱动的自主软件系统。如果你想构建一个智能体，只需掌握以下三个要素： 1. LLM引擎（大脑）以前，我们使用LLM（如LLaMA或Gemini）来总结数据或生成代码。在智能体工作流中，LLM充当推理引擎。因此，模型不是直接给出最终答案，而是被提示进行"出声思考"："我需要实现什么目标？我缺少哪些信息？下一步应该采取什么行动？" 2. 状态与记忆（上下文）智能体记住两步前做了什么非常重要。如果它尝试查询数据库时遇到认证错误，就不应该盲目地再次尝试完全相同的查询。这可能导致智能体陷入无限循环。这就是记忆的作用——允许系统维护状态跟踪器，记录过去的行动、系统观察和错误，使其能够动态更新策略。 3. 工具（手）单独的LLM无法执行操作，除非获得工具访问权限。这是因为LLM本身不知道今天的天气，无法检查Git仓库，当然也无法执行SQL查询。这就是为什么我们需要工具。工具就是你向模型公开的函数，如API、数据库连接和网页爬虫。你为LLM提供工具功能的清晰文本描述，模型决定何时使用工具以及如何调用它。 ReAct模式理解智能体的思维方式至关重要。既然我们已经了解了这三个组件，它们如何相互协作？行业标准是一种称为**ReAct（推理+行动）**的架构。 📷 （图：AI拉呱）可以把它想象成模型与自己进行的持续对话。如果你让智能体"查找Python库的最新API文档并检查是否有破坏性变更"，内部执行循环如下：思考：我需要找到最新的文档。我的训练数据中没有这些信息。我应该使用网络搜索工具。行动：调用 web_search(query="Python library API documentation 2026")。观察：搜索工具返回了一系列链接和摘要。思考：我现在可以看到新文档，但需要找出具体的破坏性变更。我将使用文本抓取工具来读取变更内容。行动：调用 fetch_page(url="...")。观察：页面显示某个特定的静态方法调用已被弃用。思考：我已找到破坏性变更。现在可以为用户构建最终答案。看看上面的循环——它完全取代了传统的、僵化的if/else逻辑。你不必为每个边缘情况编写代码，而是构建一个环境，让智能体自己找到实现目标的方法。转向基于图的AI 既然我们的重点已经转向构建智能体系统，基本的线性执行脚本已不再适用。如果你有一个需要起草文章、发送给评论智能体获取反馈，并循环直到通过阈值的智能体，线性管线会把事情搞得一团糟。这就是为什么行业正在转向基于图的架构。工具如LangGraph允许你将AI应用建模为状态机，而不是将应用视为直线：节点：代表动作（例如，LLM思考或工具执行Python脚本）。边：定义条件路径。如果LLM说**"我完成了"，边将路由到最终输出。如果LLM说"我需要更多数据"**，边将路由回工具执行节点。通过这种方式，将工作流定义为图，我们保持对系统边界的绝对控制。你获得了LLM推理的灵活性，而无需担心智能体失控。构建一个快速的ReAct智能体让我们看看使用现代Python框架时这种模式是什么样子的。好消息是你不需要成千上万行的样板代码。以下是将LLM引擎连接到可操作工具的简化示例架构： import os from langchain_core.tools import tool from langchain.agents import create_agent from langchain_openai import ChatOpenAI os.environ["OPENAI_API_KEY"] = "your-key-here" # 1. 定义工具 @tool def calculate_system_latency(requests_per_second: int) -> str: """根据活跃流量负载计算预估服务器延迟。""" if requests_per_second > 5000: return "Critical Alert: Projected latency exceeds 800ms. Optimization required." return "System stable: Projected latency is under 45ms." # 2. 初始化模型 model = ChatOpenAI(model="gpt-4o", temperature=0) tools = [calculate_system_latency] # 3. 构建智能体 agent_executor = create_agent(model, tools) # 4. 运行智能体 response = agent_executor.invoke({ "messages": [("user", "Our traffic just spiked to 6,200 requests/sec. Check our latency and tell me if we need to panic.")] }) # 5. 打印最终响应 print(response["messages"][-1].content) 现在我们的模型不再只是猜测答案。它读取工具定义，注意到6200匹配calculate_system_latency的输入签名，运行函数，捕获关键警报观察结果，并向团队显示警告。大多数人会犯的错误在你将整个代码库投入自主智能体之前，让我告诉你一个残酷的事实：如果自主性没有得到适当约束，它可能会非常昂贵。假设你构建了一个智能体，并给予它无限循环的自由，直到问题解决——一个微小的API错误可能会触发意外的无限循环。你的系统会在你睡觉时愉快地进行数千次连续LLM调用，耗尽你的预算。因此，我建议你在构建智能体系统之前遵循以下规则：硬令牌和循环限制：永远不要让智能体循环超过5或6次。严格的相似度阈值：低阈值可能导致智能体选择无关数据、产生幻觉计划并崩溃。人工介入：在状态图中设计检查点。如果智能体想要将代码推送到生产环境，确保图暂停执行直到人类点击"批准"。轮到你了我建议你从今天的日常工作流中挑选一项手动的、重复性的任务。无论是整理传入的项目请求还是总结特定的警报。使用几个Python函数，将它们连接到本地或开源模型，构建你的第一个自动化工作流。 AI只是聊天机器人回答问题的日子已经一去不复返了。我们正进入AI可以积极为我们工作的时代。现在正是开始构建不仅能回答问题，还能采取行动的系统的最佳时机。 AI拉呱：洞察AI技术前沿

331

AI拉呱-洞察AI前沿

@YanErrol168

5 days ago

Claude Code上下文管理的7个最佳开源工具 AI拉呱：洞察AI技术前沿 📷 （图：AI拉呱）即使给Claude Code提供100万token的上下文窗口，随着时间推移你仍然可能得到更差的答案。问题不仅在于上下文大小，还在于上下文质量。当终端日志、原始工具输出、重复的文件读取、冗长的响应和遗忘的项目历史都在争夺注意力时，Claude Code会话会逐渐退化。在长时间运行的智能体工作流中，这些噪音会形成一个循环：模型失去线索，你添加更多轮次来修复答案，而这些额外的轮次又添加了更多噪音。这就是上下文失焦：模型有足够的空间容纳信息，但重要信息被埋在低信号的上下文之下。更大的窗口让这个问题更容易被忽视，因为开发者不再仔细思考什么进入了提示。 📷 （图：AI拉呱）提示缓存可以减少重复前缀的成本，但它不会把上下文窗口变成杂物抽屉。你仍然需要为新token付费，仍然需要模型对正确的信息进行推理。本文回顾了七个开源工具，它们从不同层面解决上下文失焦问题：终端输出、工具输出、代码库导航、文件读取、模型冗长性、语义代码检索和跨会话记忆。什么导致了Claude Code上下文失焦？ Claude Code上下文失焦通常来自五种失败模式：过多的原始指令文本、嘈杂的工具输出、重复的代码库探索、过长的模型响应，以及跨会话或跨智能体的记忆缺口。 📷 （图：AI拉呱）一个好的上下文管理堆栈应该做三件事：保持垃圾信息不入、按需检索正确的项目知识、跨会话保留持久化决策。你应该首先使用哪个Claude Code上下文工具？从在你的工作流中产生最多噪音的层开始。如果终端输出是问题，从RTK开始。如果Claude不断在大型仓库中漫游，从claude-context或code-review-graph开始。如果你真正的痛点是每天重复解释相同的决策，从memsearch开始。 RTK在Claude看到之前压缩原始命令输出 📷 （图：AI拉呱） RTK是一个CLI代理，用于减少常见开发者命令的token使用。它的GitHub描述称其在常见开发命令上减少60-90%的LLM token消耗，并且作为单个Rust二进制文件分发。在日常Claude Code使用中，像git status、pytest和目录列表这样的命令经常将完整的环境信息和状态描述转储到上下文窗口中。模型通常只需要一个更小的答案：哪些文件被修改、哪个测试失败、PR卡在哪里，或者目录中有哪些关键文件。 RTK位于shell和Claude之间。它可以通过Claude Code钩子重写命令并传回压缩输出。原始git status输出： On branch feat/payment-retry Your branch is up to date with 'origin/feat/payment-retry'. Changes not staged for commit: modified: src/webhook/handler.ts modified: src/queue/dlq.ts modified: tests/webhook.test.ts Untracked files: docs/notes.md no changes added to commit 真正重要的信息： 3 modified, 1 untracked - src/webhook/handler.ts - src/queue/dlq.ts - tests/webhook.test.ts pytest也是一样。原始输出充满了通过的案例和环境噪音： ============================= test session starts ============================= platform darwin -- Python 3.12.4, pytest-8.4.1 collected 128 items tests/test_auth.py .................................... tests/test_webhook.py ....F.... tests/test_queue.py ................................... ================================== FAILURES ================================== ____________________________ test_retry_to_dlq ____________________________ E AssertionError: expected status code 202, got 500 压缩后，信号一目了然： 128 tests collected, 1 failed FAIL tests/test_webhook.py::test_retry_to_dlq AssertionError: expected status code 202, got 500 当你的上下文膨胀来自shell命令而不是代码检索时，RTK是最容易的起点。 Context Mode将大型工具输出沙箱化到主聊天之外 Context Mode专为工具返回的原始块而构建：测试日志、浏览器DOM快照、GitHub负载、MCP工具输出和抓取页面。其GitHub描述强调AI编码智能体的上下文窗口优化，报告98%的工具输出减少。它的方法是将大型工具输出隔离到本地沙箱和索引中，然后只将摘要和检索句柄传递到Claude对话中。这很有用，因为编码智能体通常需要失败的节点、损坏的选择器或相关的堆栈跟踪，而不是整个DOM或每一行通过的测试。Context Mode保持完整输出在本地可用，同时防止它主导主对话。 code-review-graph在Claude导航之前映射代码结构 code-review-graph解决了一个不同的问题：Claude并不总是需要更多文本；它需要更好的地图。在大型仓库中，一个简单的问题可能会触发昂贵的探索：修改此登录逻辑后，哪些文件和测试会受到影响？没有代码图，Claude的典型做法是： read auth.ts grep login read middleware read tests keep guessing code-review-graph预构建代码库的结构映射。它使用Tree-sitter解析函数、类、导入、调用关系、继承和测试依赖，然后将图写入SQLite。这使得它对于代码审查和影响范围分析非常有用。与其让Claude通过重复读取重新发现依赖图，不如让它先查询结构。 Token Savior在发送完整文件之前给Claude符号摘要 Token Savior的核心思想很简单：默认不要发送完整文件。先发送索引或符号摘要，然后仅在任务需要更多细节时再展开。如果你问支付webhook在哪里处理，模型通常不需要每个相关文件的每一行。它首先需要知道文件或符号是否相关。 Token Savior分层提供代码：这反映了开发者实际阅读代码的方式。你先扫描、确认相关性，然后只在必要时打开完整文件。 Caveman减少Claude自己的响应膨胀大多数上下文工具关注进入模型的内容。Caveman针对Claude输出的内容。 Caveman是一个Claude Code技能/插件，用于去除填充词、客套话、包装句子、过度解释和重复结构。目标不是移除知识，而是让答案更密集。没有Caveman：你的React组件重新渲染的原因可能是因为... 使用Caveman：每次渲染都是新对象引用。内联对象属性=新引用=重新渲染。用useMemo包裹。这很重要，因为Claude自己的答案会成为未来的上下文。如果每个答案都包含冗长的解释，下一轮开始时的文本就会超过实际需要。更短的答案可以像改进当前轮一样改进下一轮。 claude-context通过MCP添加语义代码搜索 claude-context通过语义检索解决重复代码库探索问题。它索引仓库，将代码块存储在向量数据库中，并通过模型上下文协议（MCP）公开搜索。在大型代码库中，你不断问Claude这样的问题：帮我找出代码中哪些部分可能与此bug相关。没有检索层，Claude的默认方法通常是： list the directory grep around read a bunch of files keep guessing claude-context将这些工作转移到检索层。它对仓库进行分块、生成嵌入、存储在Milvus支持的代码索引中，并在模型开始盲目读取文件之前检索相关代码块。 memsearch跨会话和智能体保留有用记忆 memsearch解决了问题的另一面：不是忘记什么，而是如何回忆重要的东西。想象一下你在周一告诉Claude：我们的webhook失败时无法重试——失败的事件需要进入死信队列。周三，你打开一个新会话并问： webhook层还能优化什么？没有持久记忆，Claude就好像周一的决定从未发生过一样。你需要再次解释。 memsearch将记忆存储为本地的、人类可读的Markdown文件，并使用Milvus作为可重建的检索索引。这种设计保持记忆可被人类编辑，同时仍然可以被智能体搜索。这些工具如何协同工作？这七个工具是互补的，而不是可互换的。将它们用作分层。实际的部署顺序是：首先消除明显的噪音。如果shell输出和工具负载主导你的上下文，添加RTK或Context Mode。修复仓库导航。添加code-review-graph用于结构分析，或claude-context用于语义代码检索。控制保留的内容。使用Token Savior和Caveman保持文件读取和模型响应紧凑。保留持久知识。当重复解释成为瓶颈时，使用memsearch。 AI拉呱：洞察AI技术前沿