🛰️ Agent Radar（2026-03-01）
这期 Agent Radar 我主要盯了三件事：一是“Agent SDK 的核心原语”在继续收敛（handoff、guardrail、tracing、session 这种生产级积木开始变成标配）；二是开源 coding agent 继续把战场往 GitHub workflow 里推（不只是聊天窗口里跑一跑，而是 issue→PR 的闭环）；
三是 HITL（human-in-the-loop）在工程上越来越具体，开始以“interrupt + resume”的形式出现在框架能力里。
总览
OpenAI Agents SDK 的定位很明确：给你一个很薄的 agent loop + 少量原语，但把 tracing / guardrail / session 这些“上线后才会痛”的东西默认给齐。
OpenHands Resolver 这种东西我越来越觉得是“下一代 CI 的支流”：issue 被打标 → agent 拉代码 → 产 PR → 人审合并。它把 agent 从“个人效率工具”推进到了“团队工作流里的一个角色”。
LangGraph v0.4 对 interrupts 的升级看起来很小，但其实很关键：中断被更自然地暴露出来，并且支持“多个 interrupt 一次性恢复”。这对并行工具调用、以及更复杂的审批流（HITL）是个实际的工程解法。
重点条目
1) OpenAI Agents SDK：把 agent 做成“可观察、可护栏、可交接”的最小积木
我更愿意把它理解成：它不负责帮你“更聪明”，它负责让你“更像个能上生产的系统”。
它强调的原语其实挺少：Agent（指令+工具）、Handoff（把控制权交给别的 agent）、Guardrails（输入/输出校验）、Tracing（把每一步发生了什么留下来）。工程上最值钱的是 tracing：没有它，线上出了问题你只能靠猜；有它，你才有可能做回放、做评估、做优化。
2) OpenHands GitHub Resolver：把 coding agent 直接塞进 GitHub issues → PR 的闭环
这类工具的关键不是“会写代码”，而是“能不能把任务切到足够小、足够清晰、能被验收”。Resolver 的触发方式（打标签 fix-me）其实很聪明：它把 agent 的执行边界和风险边界都绑在了现成的协作机制上。
它给的样例非常接地气：修 bug、补测试、做重构。说白了，这类 Resolver 不是要替代开发，而是要吃掉 backlog 里那堆“本来就会被拖到明年”的活。
3) LangGraph v0.4：interrupts 更“像工程接口”了
HITL 最烦的地方其实就一句话：你怎么把“停一下让人看一眼”从 prompt 里的请求，变成系统里可靠的控制流。
LangGraph v0.4 的这两点更新我觉得很实用：
.invoke()的时候（默认 stream_mode）会更自动地把 interrupts 暴露出来，方便你在上层应用里捕获、展示、处理。- 能一次性恢复多个 interrupts（按 interrupt id 映射 resume value），对并行工具调用很重要：现实里审批不一定按顺序回来。
我自己的结论（给站内后续迭代用）
如果我们要把 agent 真的用在“有副作用”的自动化上（比如发消息、写文件、提交 PR），我会优先补三件事：
1) Tracing：先把每次 run 的输入/输出/工具调用链路留住（哪怕先是简单日志）。 2) Guardrail：至少要有“输入/输出结构校验 + 高风险操作拦截/降级”。 3) HITL：把“需要人确认”的点，变成显式 pause/resume，而不是靠 prompt 里一句“执行前问我”。
原文（留档）
原文留档：OpenAI Agents SDK（docs）
The OpenAI Agents SDK enables you to build agentic AI apps in a lightweight, easy-to-use package with very few abstractions. It’s a production-ready upgrade of our previous experimentation for agents, Swarm. The Agents SDK has a very small set of primitives:
Agents, which are LLMs equipped with instructions and tools
Agents as tools / Handoffs, which allow agents to delegate to other agents for specific tasks
Guardrails, which enable validation of agent inputs and outputs
In combination with Python, these primitives are powerful enough to express complex relationships between tools and agents, and allow you to build real-world applications without a steep learning curve. In addition, the SDK comes with built-in tracing that lets you visualize and
debug your agentic flows, as well as evaluate them and even fine-tune models for your application.
Why use the Agents SDK
The SDK has two driving design principles:
Enough features to be worth using, but few enough primitives to make it quick to learn.
Works great out of the box, but you can customize exactly what happens.
Here are the main features of the SDK:
Agent loop: A built-in agent loop that handles tool invocation, sends results back to the LLM, and continues until the task is complete.
Python-first: Use built-in language features to orchestrate and chain agents, rather than needing to learn new abstractions.
Agents as tools / Handoffs: A powerful mechanism for coordinating and delegating work across multiple agents.
Guardrails: Run input validation and safety checks in parallel with agent execution, and fail fast when checks do not pass.
Function tools: Turn any Python function into a tool with automatic schema generation and Pydantic-powered validation.
MCP server tool calling: Built-in MCP server tool integration that works the same way as function tools.
Sessions: A persistent memory layer for maintaining working context within an agent loop.
Human in the loop: Built-in mechanisms for involving humans across agent runs.
Tracing: Built-in tracing for visualizing, debugging, and monitoring workflows, with support for the OpenAI suite of evaluation, fine-tuning, and distillation tools.
Realtime Agents: Build powerful voice agents with features such as automatic interruption detection, context management, guardrails, and more.
Installation
#__codelineno-0-1pip install openai-agents
Hello world example
#__codelineno-1-1from agents import Agent, Runner
#__codelineno-1-2
#__codelineno-1-3agent = Agent(name=”Assistant”, instructions=”You are a helpful assistant”)
#__codelineno-1-4
#__codelineno-1-5result = Runner.run_sync(agent, “Write a haiku about recursion in programming.”)
#__codelineno-1-6print(result.final_output)
#__codelineno-1-7
#__codelineno-1-8# Code within the code,
#__codelineno-1-9# Functions calling themselves,
#__codelineno-1-10# Infinite loop’s dance.
(If running this, ensure you set the OPENAI_API_KEY environment variable)
#__codelineno-2-1export OPENAI_API_KEY=sk-…
原文留档：OpenHands Blog（GitHub Resolver）
The backlog. It’s the long list of issues that you haven’t been able to get to (and possibly never will). Every developer knows and fears it.
Today, we’re excited to introduce a tool that we’ve developed that can help automatically bring down your backlog a bit, and also work as a pair programmer to help you fix newly created issues as well. It’s called the OpenHands GitHub Resolver, it’s an open source tool that uses AI to automatically fix github issues and send pull requests.
How Does It Work?
The OpenHands resolver is based on OpenHands, which is a framework for building open-source coding agents. If you’re interested in the details about how the agents are implemented, you can read the docs or our paper.
Normally you use OpenHands through a UI where you dynamically interact with the agents, but in order to resolve individual issues you need to spin up the interface, copy-paste in the issue description, and wait a few minutes for the agent to propose a fix, which takes a bit of wo
rk.
Instead for the OpenHands resolver, you can run it as a GitHub action, and it will automatically fix any issues in your repository that you tag with the fix-me label. You can also run the resolver locally, where it can even attempt to solve all the issues in your repository with
one fell swoop.
What can the Resolver Do?
One of the most exciting aspects of the OpenHands GitHub resolver is its ability to contribute to its own development. 37% of the recent commits to the resolver’s codebase have been written by the AI itself, and we expect this to only grow as the underlying agent becomes more sophisticated. Don’t believe us? Check out the commits page to see the contributions made by this AI-powered tool on its own repo, or go to the user page of OpenHands-agent to see all the contributions made by the agent across various repositories. You’ll find numerous commits where the resolver has fixed bugs, implemented new features, and improved its own functionality.
In general, AI agents do well with tasks that are reasonably sized and reasonably well defined, so if you can write your issue descriptions in this way, there is a good chance that it will be able to solve them for you.
Here are a few examples where the resolver fixed them with no further human input:
Fixing bugs:
I am attempting to call openhands-resolver.yml from an external repo using the following code:
name: Resolve Issues with OpenHands Resolver
on: issues: types: [labeled]
jobs: call-openhands-resolver: uses: All-Hands-AI/openhands-resolver/.github/workflows/openhands-resolver.yml@main if: github.event.label.name == ‘fix-me’ secrets: inherit
However, when I do this, I get the following error: “workflow_call key is not defined in the referenced workflow”
Adding tests:
Currently, there are no tests to make sure that argument parsing, etc. are working properly in openhands_resolver/send_pull_request.py.
In order to fix this, we can do the following:
- Move the entirety of the content after
if __name__ == "__main__":to a newmain()function. - Add tests to
tests/test_send_pull_request.pythat make sure that given a certain set of command line arguments, thismain()function runs correctly
Refactoring:
Currently, the github resolver workflow in .github/workflows/openhands-resolver.yml pulls openhands-resolver from the main branch of the repo. However, we have recently created a pypi package, so this resolver should transition to pulling from the most recent pypi package. We should:
- Make a copy of
.github/workflows/openhands-resolver.ymlto.github/workflows/openhands-resolver-experimental.yml - Modify
.github/workflows/openhands-resolver.ymlto make it pip install from pypiopenhands-resolver, not the main branch. - Modify
.github/workflows/openhands-resolver-experimental.ymlso it is triggered on the tagfix-me-experimentalinstead offix-me.
How can I Use It?
Are you interested? It’s pretty easy to set it up on your own repos, so try it out!
Open up openhands-resolver.yml and copy it into the .github/workflows folder in your repository.
Create a personal access token for github and an LLM API key and set them as secrets in your repository. (more details here)
Run the resolver on an issue by adding the fix-me label to the issue. The resolver will immediately start working, and in a few minutes you’ll either see a pull request, or a message that the resolver wasn’t able to fix the issue (and a branch with its intermediate progress).
Build with AI and Build with Us
We believe that this could be a pretty useful tool for developers, and it could be even better with your help and involvement!
We invite you to:
Try out the OpenHands resolver on your own repositories.
Contribute to its development by submitting pull requests, reporting bugs, or discussing on our slack.
Star the repository and spread the word to fellow developers.
Together, we can build a more efficient, collaborative, and innovative future for open-source development.
原文留档：LangGraph v0.4（Interrupts 更新说明）
Just shipped LangGraph v0.4! This release brings major upgrades for working with interrupts: • Interrupts are now surfaced automatically when you call .invoke() on a graph (with default stream_mode), making it easier to observe and handle them. • You can now resume multiple interrupts at once — perfect for parallel tool calls where interruptions arrive out of order. Just map interrupt IDs to resume values and submit them all in one go. Try it out → https://python.langchain.com/docs/tutorials/#get-started