标签：#langgraph

AI agents are getting very good at doing things . They can search databases, call APIs, modify tickets, draft code, update records, trigger workflows, and interact with production systems. And that changes the engineering problem. When an LLM only generates text, a bad answer is usually just that: a bad answer. When an LLM can take an action, a bad answer can become a bad state change . So the most important question in agent architecture is no longer: Can the model figure out what to do? It is: Who decides whether the model should actually be allowed to do it? Those are two very different responsibilities. And I think one of the most useful principles for production AI agents is surprisingly simple: Use the model to reason. Don’t automatically give it authority to execute. The architecture that works beautifully in demos A lot of agent demos reduce to something like this: User → LLM → Tool → Action The model receives a request. It reasons about what should happen. It selects a tool. It generates the parameters. The tool executes. That is an incredibly productive abstraction. It is also a risky one when the tool can affect something real. The same probabilistic system is effectively doing two jobs: deciding what it believes should happen; authorizing that thing to happen. You can try to fix this with prompting: Always ask for confirmation before making important changes. But that is still an instruction. It is not a security boundary. The difference becomes clearer when you compare the two architectures. %%{init: {'theme':'base','themeVariables': { 'primaryTextColor':'#111827', 'secondaryTextColor':'#111827', 'tertiaryTextColor':'#111827', 'textColor':'#111827', 'edgeLabelBackground':'#FFFFFF', 'lineColor':'#4B5563' }}}%% flowchart LR subgraph BAD["❌ Demo-Style Agent"] direction LR A["User"] --> B["🧠 LLM"] B --> C["🔧 Tool"] C --> D["💥 Real-World Action"] end subgraph GOOD["✅ Production-Oriented Agent"] direction LR E["User"] --> F["🔎 Evidence"] F --> G["🧠 LLM"] G --

The False Dichotomy The agent ecosystem is split into two camps: Camp Loops (Boris Cherny, OpenAI Agents SDK, LangGraph): > "Agents are loops. Plan → act → observe → repeat. The loop is the atomic unit." Camp Graphs (Steve Yegge, Gas Town, LangGraph DAGs, CrewAI): > "Agents are graphs. Nodes are agents/tools. Edges are handoffs. The graph is the architecture." Both are right. Both are incomplete. What Loops Get Right Loops capture temporal behavior — the iterative, self-correcting nature of agent work: - Replanning on failure (AdaPlanner, ReAct) - Budget enforcement (token caps, step limits, cost ceilings) - Verification gates (process reward models, extraction floors) - Learning loops (feedback → lessons → advisory → suppress) A loop is a control structure. It says: keep going until condition X. What Graphs Get Right Graphs capture structural composition — how capabilities connect: - Handoffs (peer-to-peer control transfer) - Parallel execution (swarms, polecats, fan-out/fan-in) - Supervision trees (Erlang/OTP-style restart strategies) - Provenance (who called whom, with what context) A graph is a dependency structure. It says: A feeds B, B feeds C, C can restart A. The Missing Layer: A Compiler Between Repos and Runtime Here's what neither camp addresses: Where do the nodes come from? Today: - You find a repo on GitHub - You hope it implements what it claims - You wire it into your graph/loop - You pray it works There's no verification layer. No SBOM. No attestation. No provenance. HURCULES: The Compiler Between Repos and Runtime HURCULES sits between the repository and the agent runtime: GitHub Repository → HURCULES → Verified Capability Package → Agent Runtime (Loop or Graph) It doesn't care if your runtime is a loop or a graph. It produces verified capabilities that work in either. What HURCULES Compiles | Input | Output | |-------------------------------|---------------------------------------------------| | Raw repo (any language) | Deterministic map (file tr

Every developer has been there: you clone a promising repository, and the README is either missing, three years stale, or says "docs coming soon." Even when documentation exists, you still have to wade through thousands of lines of code to understand the architecture, entry points, and dependencies. grow-hack is an open-source project that aims to eliminate that pain. Paste a public GitHub URL, wait about sixty seconds, and receive a complete, professional documentation package — Markdown and styled PDF — generated by an LLM that actually reads the code, not just the README. This is the first module of a larger content creation platform. The core idea is that once a repository is parsed and analyzed, the resulting RepositoryKnowledge object becomes a reusable asset for future modules: blog posts, LinkedIn articles, X threads, tutorials, and presentations. In this teardown, we'll look at how grow-hack works, the smart engineering choices it makes, and why it's more than just a documentation generator. The Pipeline: From URL to PDF The application is a Flask web app that orchestrates a LangGraph-based agent pipeline. The flow is straightforward: Flask UI -> LangGraph workflow -> GitHub fetch -> Parser -> Analyzer -> Knowledge object -> Documentation generator -> Reviewer -> Markdown/PDF Each stage is handled by a dedicated agent: GitHub Agent ( agents/github_agent.py ): Validates the URL, fetches metadata via the GitHub REST API (using PyGithub), and clones the repository with GitPython. Parser ( services/parser.py ): The workhorse. It walks the repository tree, ignoring generated directories and binary files, and extracts README, configuration files, dependencies, and source code structure. It infers the language, framework, package manager, entry points, and overall architecture. Analysis Agent ( agents/analysis_agent.py ): Takes the parsed data and, with the help of an LLM, produces a structured RepositoryKnowledge object. Documentation Agent ( agents/documentation

AI Agent 市场设计:让 Agent 像 App 一样被交易与编排 App Store 把「软件」变成了可被一键购买、安装、评分的商品,AI 时代对应的实体是「Agent」。一个 Agent = 一段可被复用的提示词 + 工具集 + 知识库 + 模型路由配置。本文讲清楚一个 Agent 市场需要哪些核心机制,以及 IHUI-AI 的实现路径。 一、Agent 市场的产品定义 什么是「可上架的 Agent」 不是所有对话 prompt 都能成为商品。一个可上架的 Agent 必须满足: 可独立运行 :用户购买后能立刻用,不需要再写代码。 可复用 :不同用户用同一个 Agent 都能得到稳定结果。 可定价 :有明确的使用边界(次数 / 时长 / 调用规模)。 可评估 :有客观的质量指标(成功率 / 满意度 / 失败率)。 Agent 定义格式 IHUI-AI 用一份 schema 描述可上架的 Agent: const MarketplaceAgentSchema = z . object ({ id : z . string (). uuid (), name : z . string (), description : " z.string(), " // 核心能力 systemPrompt : z . string (), tools : z . array ( z . string ()), // 引用工具/MCP server knowledgeBases : z . array ( z . string ()), // 绑定 RAG 知识库 modelRouting : z . object ({ default : z . string (), // 默认模型 fallback : z . string (). optional (), // 降级模型 }), // 定价 pricing : z . object ({ model : z . enum ([ " free " , " subscription " , " per_call " , " revenue_share " ]), price : z . number (), currency : z . string (). default ( " CNY " ), trialQuota : z . number (). default ( 0 ), }), // 评估 metrics : z . object ({ successRate : z . number (), avgLatencyMs : z . number (), rating : z . number (). min ( 0 ). max ( 5 ), usageCount : z . number (), }), }); 二、四种定价模型 模型 适用 优点 缺点 免费(Free) 引流、品牌 Agent 易扩散 无直接收入 订阅(Subscription) 高频工具型 Agent 收入稳定 流失需运营 按调用计费(Per Call) 低频高价值 Agent 与成本对齐 用户预算焦虑 分成(Revenue Share) 内容生成型 Agent 创作者激励 结算复杂 IHUI-AI 默认采用 订阅 + 按调用混合 :基础功能订阅包月,超出额度按调用计费,创作者拿 70% 分成。 三、Agent 质量评估:四维评分 简单的「5 星好评」不够,因为容易被刷分。IHUI 用四维加权: 任务成功率(40%) :Agent 完成用户原始任务的比率,由 LLM-as-Judge 自动评估。 用户评分(25%) :真实用户打分,过滤异常分布(全是 5 星或 1 星)。 响应延迟(15%) :首 token 时延 + 总时长,归一化到 [0,1]。 稳定性(20%) :错误率 + 重试率,错误越少分越高。 def agent_score ( metrics ) -> float : return ( 0.40 * min ( metrics . success_rate , 1.0 ) + 0.25 * metrics . user_rating / 5 + 0.15 * ( 1 - min ( metrics . p95_latency / 30_000 , 1 )) + 0.20 * ( 1 - min ( metrics . error_rate / 0.1 , 1 )) ) 这个分数实时更新,作为市场搜索排序的依据。 四、Agent 编排:从单个 Agent 到 Agent 工作流 单个 Agent 的能力有上限。Agent 市场的真正价值在于「让用户像搭积木一样编排多个 Agent」。

Approval workflows do not fail only at the model layer. In a production agent, the more common failure is losing the exact paused state that a reviewer was supposed to approve. Why can a saver decide LangGraph approvals? A saver can decide LangGraph approvals because approvals depend on persisted graph state, not just a chat transcript. LangGraph interrupts pause execution inside a node, store the current state, wait until a human decision arrives, and resume the intended checkpoint with Command(resume=...) ; without a saver tied to the same thread_id , the reviewer handoff can resume the wrong point or fail to resume at all . Quick Answer: LangGraph approvals work only when the paused run is checkpointed and resumed through the same thread_id . LangSmith adds the audit layer: each trace is capped at 25,000 runs, and SaaS trace retention is documented as 400 days from ingestion . The practical rule is simple: put the checkpoint before the irreversible action. That means email sends, file writes, deploys, database mutations, support-ticket edits, purchases, payments, outbound messages, and code execution should pause before the side effect. LangChain's HumanInTheLoopMiddleware follows the same shape: inspect tool calls after model output but before execution, then allow an approve, edit, or reject decision against a checkpointed run . "Interrupts are designed to pause graph execution and resume from the saved point," according to the official LangGraph interrupts documentation . For developers, the important part is operational: the approval gate is only trustworthy if the persisted checkpoint and reviewer decision refer to the same run. LangSmith then gives the team evidence that the gate is behaving correctly. Its observability model groups execution into projects, traces, runs, and threads, which lets teams audit latency, rejection reasons, retry count, tool failures, and reviewer decisions instead of debugging from logs alone . The seed video is useful background

Handoffs are useful when a specialist agent needs to take over a task. They also make cost easier to hide, because the bill is spread across graph nodes instead of one visible chat turn. Why can LangGraph handoffs multiply tokens? LangGraph handoffs can multiply tokens because each model-calling node may resend instructions, prior messages, retrieved material, tool returns, summaries, and artifacts, then loops or handoffs repeat that payload for the next agent. Token amplification is the total prompt-plus-completion tokens across a trace divided by a simpler baseline for the same task; Anthropic reported in June 2025 that multi-agent systems used about 15x more tokens than chats while improving an internal research evaluation by 90.2% . Quick Answer: Handoffs raise the token bill when each agent receives copied context instead of a narrow task packet. Anthropic’s June 2025 research system showed the tradeoff clearly: multi-agent runs used about 15x more tokens than chats while scoring 90.2% higher on its internal research evaluation . In LangGraph, the practical issue is observability and budgeting, not whether graphs are bad. The LangGraph project describes the runtime as a way to build stateful, long-running agents with persistence, human control, memory, and debugging support; those same traits make it possible to measure where context grows instead of guessing. "Multi-agent systems are often highly effective at open-ended research tasks, but token usage can be substantial," — Anthropic engineering team at Anthropic The small verified demo below shows the arithmetic behind a 15x bill: a 100-token task becomes 1,500 billed tokens when 5 agents each receive 3 copies of the relevant context . """ Tiny token-accounting demo: handoffs multiply the same task context. """ task_tokens = 100 agents = 5 context_copies_per_handoff = 3 # instructions + task + summary/history direct_bill = task_tokens handoff_bill = task_tokens * agents * context_copies_per_handoff print ( f

LangGraph isn't cheaper than LangChain — unless you opt out of its defaults Cost-audit series, episode 4. This series began with an AI agent that burned 136M tokens overnight → . When LangChain deprecated ConversationBufferMemory (the subject of episode 1 in this series), the official migration path was LangGraph. The pitch: explicit state management, you control exactly what flows where. More expressive, more controllable. It is — but only if you reach for the controls. The default state model in LangGraph has the same unbounded-growth problem as the memory it replaced. Teams migrating to escape ConversationBufferMemory's cost curve often land on an identical curve, with new graph complexity on top. This audit shows exactly where the default grows, what it costs, and what opt-outs exist. The default: MessagesState + add_messages The quickstart in LangGraph's own docs uses this pattern: from langgraph.graph import StateGraph , MessagesState def my_node ( state : MessagesState ): messages = state [ " messages " ] response = llm . invoke ( messages ) # sends ALL messages to the LLM return { " messages " : [ response ]} graph = StateGraph ( MessagesState ) graph . add_node ( " agent " , my_node ) MessagesState is a TypedDict with a single key, messages , backed by the add_messages reducer. Here's what that reducer does: # langgraph/graph/message.py — add_messages (def at line 18; merge loop below) def add_messages ( left : Messages , right : Messages ) -> Messages : # ... (coerces left/right to lists of BaseMessage) ... left_idx_by_id = { m . id : i for i , m in enumerate ( left )} merged = left . copy () ids_to_remove = set () for m in right : if ( existing_idx : = left_idx_by_id . get ( m . id )) is not None : if isinstance ( m , RemoveMessage ): ids_to_remove . add ( m . id ) else : merged [ existing_idx ] = m # same id → update in place else : merged . append ( m ) # new id → APPEND (the list grows) merged = [ m for m in merged if m . id not in ids_to_remove ] retu

Day 1 · by Kunal Hore ( @KunalOnTech ) Quick Jump Why I'm Learning This Publicly Today's Map 1. State 2. Nodes 3. Edges 4. Build & Run — The Full Exercise Kunal's Interview Corner Today's Takeaway Most code runs top to bottom, once, with no memory of where it's been. Real decisions don't move in a straight line — sometimes you loop back, sometimes you branch depending on what just happened. A script can't pause mid-run and reconsider. A graph can. That single difference — code that can stop, decide, and circle back instead of just executing — is the entire reason LangGraph exists. Over the next few days I'll cover all the topics to make you familiar with LangGraph. This is my first day of learning, and I'll share whatever I learn along the way. Today it's the three basics — what a graph remembers ( state ), what counts as one step (a node ), and how those steps connect (an edge ). We won't just talk about them — we'll build a small hands-on exercise with real code, because I've always believed you learn by building, not by theory alone. Kunal's one-liner: "Code that only moves forward can't think. Code that can loop back, can." That's the whole pitch for today. Everything else — TypedDict, function signatures, edge syntax — is just the mechanics of making that one idea real in Python. Why I'm Learning This Publicly I'm learning LangGraph from zero — one concept a day. No shortcuts, no pretending I already know it. Whatever I learn each day, I share the same day: the wins, the confusion, the "oh THAT'S what it means" moments, all of it. My goal is simple: One concept per day, explained with everyday analogies — no jargon walls Real code every single day, because you learn by building, not by theory alone Write it the way I wish someone had explained it to me Your goal, if you learn alongside me: by the end of this series, we'll both be able to design and build stateful AI agents — the kind of systems that can decide, branch, retry, and loop, not just respond once. An

Revolutionizing Content Automation: Building Multi-Agent Pipelines with LangGraph TL;DR : LangGraph transforms AI content automation by enabling sophisticated multi-agent systems. It orchestrates specialized agents for complex tasks, integrates seamlessly with Celery for asynchronous task management, and uses Redis for efficient state tracking. This framework surpasses traditional workflows by supporting dynamic decision-making and complex agent interactions. Introduction Imagine content automation systems that are intelligent and adaptive, capable of understanding context and making decisions autonomously. LangGraph, a cutting-edge framework, is making this vision a reality by empowering developers to build dynamic, multi-agent content pipelines. As AI engineers and system architects strive to automate intricate content processes, LangGraph offers a robust alternative to traditional linear workflows, promising enhanced efficiency and adaptability. LangGraph's Orchestration Capabilities LangGraph excels in orchestrating multiple specialized agents within a single pipeline. Unlike traditional systems, which often rely on linear processes, LangGraph enables the simultaneous operation of various agents, each with specific roles and expertise. Key Features Agent Specialization : Engineers can design agents specialized in tasks such as research, writing, editing, and publishing. Each agent functions independently yet collaboratively within the pipeline. Dynamic Interactions : Agents interact in real-time, sharing data and insights to refine content outputs collectively. Complex Task Handling : The architecture supports complex task management, ensuring each agent contributes effectively to the overall goal. Multi-Agent Collaboration and Specialization The core of LangGraph is its multi-agent collaboration mechanism. This shift from linear workflows to collaborative systems enables specialization, significantly improving the quality and efficiency of content automation. B

We’ve all been there. You have a "Leg Day" scheduled in your Notion database, but you woke up feeling like a truck hit you. Your Apple Watch says your Heart Rate Variability (HRV) is in the gutter, but your rigid calendar doesn't care. Usually, you’d either push through and risk injury or manually move cards around in Notion—which is a friction-filled nightmare. In this tutorial, we are building a Self-Optimizing Health Agent using LangGraph , Notion API , and HealthKit . This agent acts as a closed-loop system: it analyzes your physiological recovery data, reasons about your physical state using an LLM, and automatically rewrites your training schedule. By mastering AI agents , LLM orchestration , and fitness automation , you’ll turn your static "To-Do" list into a dynamic "Should-Do" list. 🥑 The Architecture: The Bio-Feedback Loop Using LangGraph , we can treat our fitness logic as a state machine. Unlike a linear script, a graph allows our agent to decide whether it needs to fetch more context (like yesterday's sleep) before making a final decision on your workout. graph TD Start((Start)) --> FetchHRV[Fetch HRV Data via HealthKit] FetchHRV --> CheckRecovery{LLM: Analyze Recovery} CheckRecovery -- "Low Recovery (Fatigued)" --> ModifyNotion[Action: Downgrade Workout Intensity] CheckRecovery -- "High Recovery (Fresh)" --> KeepNotion[Action: Maintain/Boost Intensity] ModifyNotion --> UpdateNotion[Update Notion Page] KeepNotion --> UpdateNotion UpdateNotion --> End((Done)) style CheckRecovery fill:#f96,stroke:#333,stroke-width:2px style FetchHRV fill:#bbf,stroke:#333 Prerequisites Before we dive into the code, ensure you have: Python 3.10+ LangChain & LangGraph installed ( pip install langgraph langchain_openai ) Notion Integration Token (with access to your workout database) HealthKit SDK (Note: Since we are in a Python environment, we'll simulate the HealthKit fetcher, though in a real-world scenario, this would be bridged via a FastAPI endpoint from an iOS app). St