# What to Learn, Build, and Skip in AI Agents (2026)
**作者**: Rohit
**日期**: 2026-04-29T17:56:09.000Z
**来源**: [https://x.com/rohit4verse/status/2049548305408131349](https://x.com/rohit4verse/status/2049548305408131349)
---
Every day brings a new framework, a new benchmark, a new "10x" launch. The question stops being "how do I keep up." It becomes: what's actually signal here, and what's noise wearing the costume of urgency.
Every roadmap goes obsolete a month after launch. The framework you mastered last quarter is now legacy. The benchmark you optimized for got gamed and replaced. We were conditioned to follow a conventional path: a stack with topics and levels, a sequence of jobs and tenures, a slow climb. AI rewrote that canvas. Anyone with the right prompts and the right taste can now ship work that used to take a 2-year-experience engineer a sprint.
Expertise still matters. Nothing replaces having watched systems break, having debugged a memory leak at 2am, having argued for a boring choice over a clever one and been right. That kind of taste compounds. What stopped compounding the way it used to: knowing this week's framework's API surface. Six months from now it will be different. The people winning in two years picked durable primitives early and let the rest pass them by.
I've spent two years building in this space, cracked multiple offers north of $ 250k, and now run technical at a company in stealth. This is what I'd send to someone asking "what should I actually be paying attention to right now."
It is not a roadmap. The agent field doesn't have a destination yet. The big labs are iterating in public, shipping regressions to millions of users, writing postmortems, patching live. If the team behind Claude Code can ship a 47% performance regression and only catch it after the user community does, the idea that there's a stable map underneath all this is fiction. Everyone is figuring it out. Startups are flourishing because the giants don't know either. Non-coders are pairing with agents and shipping things on Friday that ML PhDs were calling impossible on Tuesday.
The interesting thing about this moment is what it does to the question of credentials. The conventional path optimized you for credentials: degree, junior role, senior role, staff role, the slow accumulation of rank. That made sense when the field underneath you didn't move. The field now moves under everyone equally. The difference between a 22-year-old shipping agent demos in public and a 35-year-old senior engineer is no longer ten years of accumulated stack mastery. The 22-year-old has the same blank canvas the senior has, and what compounds for either of them is willingness to ship, plus the small list of primitives that don't go obsolete in a quarter.
That's the reframe this whole piece is built on. What follows is a way to think about which primitives are worth your attention and which launches to let pass. Pick what fits. Leave what doesn't.
## The filter that actually works
You can't keep up with weekly launches. You shouldn't try. The thing you need is a filter, not a feed.
Five tests have held up across the last 18 months. Run a launch through them before you let it touch your stack.
Will this matter in two years? If it's a wrapper around a frontier model, a CLI flag, or "Devin but for X," the answer is almost always no. If it's a primitive (a protocol, a memory pattern, a sandboxing approach), the answer is more often yes. The half-life of wrappers is short. The half-life of primitives is years.
Has someone you respect built something real on top of it and written about it honestly? Marketing posts don't count. Postmortems do. A blog called "we tried X in production and here's what broke" is worth ten launch announcements. The good signal in this field is always written by someone who has lost a weekend to it.
Does adopting it require you to throw away your tracing, your retries, your config, your auth? If yes, it's a framework trying to be a platform. Frameworks-trying-to-be-platforms have a 90% mortality rate. The good primitives slot into your existing system without forcing a migration.
What does it cost you to skip this for six months? For most launches, the answer is nothing. You'll know more in six months. The winning version will be clearer. This is the test that lets you skip 90% of launches without anxiety, and the one most people refuse to run because skipping feels like falling behind. It isn't.
Can you measure whether it actually helps your agents? If you can't, you're guessing. Teams without evals run on vibes and ship regressions. Teams with evals can let the data tell them whether GPT-5.5 or Opus 4.7 wins on their specific workload this week.
If you adopt one habit from this whole piece, make it this: when something new launches, write down what you'd need to see in six months to believe it matters. Then come back and check. Most of the time the question will have answered itself, and you'll have spent your attention on things that compound.
The skill underneath these tests is harder to name than any of them. It's the willingness to be uncool about what you don't pick up. The framework that goes viral on Hacker News this week will have an army of cheerleaders for fourteen days, and they will all sound smart. Six months later, half of those frameworks are unmaintained and the cheerleaders have moved on. The people who didn't engage saved their attention for things that survived the test of being boring after the launch hype passed. That posture, holding back, watching, saying "I'll know in six months," is the actual professional skill of this field. Everyone can read launches. Almost nobody is good at not reacting to them.
## What to learn
Concepts. Patterns. The shape of things. These are the ideas that pay compounding returns. They survive model swaps, framework swaps, paradigm shifts. Understand them deeply and you can pick up any new tool in a weekend. Skip them and you'll be perpetually re-learning surface mechanics.
Context engineering
The most important rename of the last two years was "prompt engineering" becoming "context engineering." The shift is real, not cosmetic.
The model is no longer something you craft a clever instruction for. It's something you assemble a working context for at every step. That context is system instructions, tool schemas, retrieved documents, prior tool outputs, scratchpad state, and compressed history all at once. The agent's behavior is an emergent property of what you put in the window.
Internalize this: context is state. Every token of irrelevant noise costs you reasoning quality. Context rot is a real production failure. By step eight of a ten-step task, the original goal can be buried under tool output. The teams that ship reliable agents actively summarize, compress, prune. They version their tool descriptions. They cache the static parts and refuse to cache the parts that change. They think about the context window the way an experienced engineer thinks about RAM.
A concrete way to feel this: take any agent in production and turn on full trace logging. Look at the context at step one. Look at the context at step seven. Count how many of those tokens are still earning their keep. The first time you do this, you'll be embarrassed. Then you'll go fix it, and the same agent will get noticeably more reliable without any change to the model or the prompt.
If you read one thing on this, read Anthropic's "Effective Context Engineering for AI Agents." Then read their multi-agent research postmortem, which puts numbers on how much context isolation matters once you scale up.
Tool design
Tools are where agents meet your business. The model picks tools based on names and descriptions. The model retries based on error messages. The model fails or succeeds based on whether the tool's contract matches what an LLM is good at expressing.
Five to ten well-named tools beat twenty mediocre ones. Tool names should read like English verb phrases. Descriptions should include when to use the tool and when not to. Error messages should be feedback the model can act on. "Max tokens 500 exceeded, try summarizing first" beats "Error: 400 Bad Request" by an enormous margin. One team in the public research reported a 40% reduction in retry loops after rewriting their error messages alone.
Anthropic's "Writing tools for agents" is the right starting point. After that, instrument your own tools and look at the actual call patterns. The biggest wins in agent reliability are almost always tool-side. People keep tuning prompts and ignoring the place where the actual leverage lives.
The orchestrator-subagent pattern
The multi-agent debate of 2024 and 2025 ended with a synthesis everyone now ships. Naïve multi-agent systems, where multiple agents write to shared state in parallel, fail catastrophically because errors compound. Single-agent loops scale further than you'd expect. There is one multi-agent shape that works in production: an orchestrator agent that delegates narrowly scoped read-only tasks to isolated subagents, then synthesizes their results.
This is how Anthropic's research system works. It's how Claude Code's subagents work. It's the pattern Spring AI and most production frameworks now standardize. Subagents get small, focused contexts. They cannot mutate shared state. The orchestrator owns the writes.
Cognition's "Don't Build Multi-Agents" essay and Anthropic's "How we built our multi-agent research system" look like opposites and are saying the same thing in different vocabularies. Read both.
Default to single-agent. Reach for orchestrator-subagent only when the single agent hits a real wall: context window pressure, latency from sequential tool calls, or task heterogeneity that genuinely benefits from focused contexts. Building this before you've felt the pain ships complexity you don't need.
Evals and golden datasets
Every team that ships reliable agents has evals. Every team that doesn't, doesn't. This is the single highest-leverage habit in the field, and it's the most under-invested thing I see at every company I've looked at.
What works: harvest your production traces, label the failures, treat that as a regression set. Add to it whenever a new failure ships. Use LLM-as-judge for the subjective parts, exact-match or programmatic checks for the rest. Run the suite before any prompt, model, or tool change. Spotify's engineering blog reported their judge layer vetoes about 25% of agent outputs before they ship. Without it, one in four bad results would have reached users.
The mental model that makes this stick: an eval is a unit test that holds the agent honest while everything else changes underneath it. The model gets a new version. The framework releases a breaking change. The vendor deprecates an endpoint. Your evals are the only thing that tells you whether your agent is still doing its job. Without them, you're writing a system whose correctness depends on the goodwill of a moving target.
The eval frameworks (Braintrust, Langfuse evals, LangSmith) are fine. None of them is the bottleneck. The bottleneck is having a labeled set in the first place. Build that on day one, before you scale anything. The first fifty examples can be hand-labeled in an afternoon. There is no excuse.
File-system-as-state and the think-act-observe loop
For any agent doing real multi-step work, the durable architecture is: think, act, observe, repeat. The file system or a structured store as the source of truth. Every action logged and replayable. Claude Code, Cursor, Devin, Aider, OpenHands, goose. They all converged on this for a reason.
The model is stateless. The harness has to be stateful. The file system is a stateful primitive every developer already understands. Once you accept this framing, the whole harness discipline (checkpointing, resumability, sub-agent verification, sandboxed execution) falls out of taking the pattern seriously.
The deeper thing this is teaching you: the harness is doing more work than the model in any production agent worth its compute bill. The model picks the next action. The harness validates it, runs it in a sandbox, captures the output, decides what to feed back, decides when to stop, decides when to checkpoint, decides when to spawn a subagent. Swap the model for a different one of similar quality and a good harness still ships. Swap the harness for a worse one and the best model in the world still produces an agent that randomly forgets what it was doing.
If you are building anything more elaborate than a single-shot tool call, the harness is where you should be spending your time. The model is a component inside it.
MCP, conceptually
Don't just learn how to call MCP servers. Learn the model. A clean separation between agent capabilities, tools, and resources, with an extensible auth and transport story underneath. Once you understand it, every other "agent integration framework" you see will look like a worse version of MCP, and you'll save the time of evaluating each one.
The Linux Foundation now stewards it. Every major model provider backs it. The "USB-C of AI" comparison is more accurate than ironic now.
Sandboxing as a primitive
Every production coding agent runs in a sandbox. Every browser agent has been hit by indirect prompt injection. Every multi-tenant agent has had a permission scoping bug shipped at some point. Treat sandboxing as primitive infrastructure, not a feature you add when a customer asks.
Learn the basics. Process isolation. Network egress controls. Secret scoping. Auth boundaries between agent and tool. The teams that bolt this on after a customer security review are the teams that lose the deal. The teams that build it in from week one pass enterprise procurement without sweating.
## What to build with
Specific picks, April 2026. These will shift, but slowly. Pick boringly here.
Orchestration
LangGraph is the production default. Roughly a third of large companies running agents use it. The abstractions match the real shape of agent systems: typed state, conditional edges, durable workflows, human-in-the-loop checkpoints. The downside is verbosity. The upside is that the verbosity matches what you actually need to control once an agent is in production.
If you live in TypeScript, Mastra is the de facto pick. Cleanest mental model in that ecosystem.
If your team loves Pydantic and wants type safety as a first-class citizen, Pydantic AI is a reasonable greenfield choice. It hit v1.0 in late 2025 and the momentum is real.
For provider-native work (computer use, voice, real-time), use Claude Agent SDK or OpenAI Agents SDK inside your LangGraph nodes. Don't try to make either the top-level orchestrator for a heterogeneous system. They're optimized for their lane.
Protocol layer
MCP, full stop. Build your tool integrations as MCP servers. Consume external integrations the same way. The registry has crossed the point where you can almost always find a server before you need to build one. Wiring custom tool plumbing in 2026 pays a tax for nothing.
Memory
Pick by autonomy level, not by hype.
Mem0 for chat-style personalization. User preferences, light history. Zep for production conversational systems where state evolves and you need entity tracking. Letta when an agent maintains coherence across days or weeks of work. Most teams will not need this. The ones that do, need exactly this.
The mistake is reaching for a memory framework before you have a memory problem. Start with whatever your context window can hold plus a vector store. Add a memory system only when you can articulate the failure mode it solves.
Observability and evals
Langfuse is the OSS default. Self-hostable, MIT-licensed, covers tracing, prompt versioning, and basic LLM-as-judge evals. If you're already a LangChain shop, LangSmith integrates more tightly. Braintrust is the right pick for research-style eval workflows with rigorous comparisons. OpenLLMetry / Traceloop is the answer if you need vendor-neutral OpenTelemetry instrumentation in a polyglot stack.
You want both tracing and evals. Tracing answers "what did the agent actually do?" Evals answer "is the agent better or worse than yesterday?" Don't ship without both. The cost of running blind is ten times the cost of wiring this up properly on day one.
Runtime and sandbox
E2B for general sandboxed code execution. Browserbase (paired with Stagehand) for browser automation. Anthropic Computer Use when you need real OS-level desktop control. Modal for short-lived bursts. Don't run unsandboxed code execution. Ever. The blast radius of a single prompt-injected agent in your production environment is a story you don't want to tell.
Models
The benchmark chase is exhausting and largely unhelpful. Pragmatically, in April 2026:
Claude Opus 4.7 and Sonnet 4.6 for reliable tool use, multi-step coherence, and graceful failure recovery. Sonnet is the cost-performance sweet spot for most workloads. GPT-5.4 and 5.5 when you need the strongest CLI/terminal reasoning or you live in OpenAI infra. Gemini 2.5 and 3 for long-context-heavy or multimodal-heavy jobs. DeepSeek-V3.2 or Qwen 3.6 when cost matters more than top-end performance, especially for narrow well-defined tasks.
Treat models as swappable. If your agent only works with one model, that's a smell, not a moat. Use evals to decide what to deploy. Re-evaluate every quarter, not every week.
## What to skip
You will be told to learn and build with all of these. You don't need to. The cost of skipping is low. The time saved is large.
AutoGen and AG2 for production. Microsoft's framework moved to community maintenance, releases stalled, abstractions don't match what production teams actually need. Fine for academic exploration. Don't anchor a product on it.
CrewAI for new production builds. It's everywhere because it demos easily. Engineers building real systems have moved off it. Use it for prototypes if you want. Don't commit to it.
Microsoft Semantic Kernel unless you're locked into the Microsoft enterprise stack and your buyers care that you are. It's not where the ecosystem is heading.
DSPy unless you're specifically optimizing prompt programs at scale. Philosophical merit, niche audience. Not a general agent framework. Don't pick it as one.
Standalone code-writing agents as your architecture choice. Code-as-action is interesting research. It isn't a production-default pattern yet, and you'll fight tooling and security battles your competitors don't have.
"Autonomous agent" pitches. The AutoGPT and BabyAGI lineage is dead in product form. The honest framing the industry settled on is "agentic engineering": supervised, bounded, evaluated. Anyone still selling deploy-and-forget autonomous agents in 2026 is selling you 2023.
Agent app stores and marketplaces. Promised since 2023, never delivered enterprise traction. Enterprises don't buy generic pre-built agents. They buy vertical agents tied to outcomes, or they build their own. Don't structure your business around an app-store dream.
Horizontal "build any agent" enterprise platforms as a customer (Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio tier). They'll be useful eventually. Right now they're confusing, slow-shipping, and the buy-versus-build math still favors building the narrow agent yourself or buying the vertical one. Salesforce Agentforce and ServiceNow Now Assist are exceptions because they win by being embedded in workflow systems you already use.
SWE-bench and OSWorld leaderboard chasing. Berkeley researchers documented through 2025 that nearly every public benchmark can be gamed without solving the underlying task. Teams now use Terminal-Bench 2.0 and their own internal evals as the real signal. Treat single-number benchmark leaps with skepticism by default.
Naïve parallel multi-agent architectures. Five agents chatting over shared memory looks impressive in a demo and falls apart in production. If you can't draw a clean orchestrator-subagent diagram with read/write boundaries on a napkin, don't ship it.
Per-seat SaaS pricing for new agent products. The market moved to outcome and usage based. Pricing per seat leaves money on the table and signals to buyers that you don't trust your own product to deliver outcomes.
The next framework you see on Hacker News this week. Wait six months. If it still matters, it'll be obvious. If it doesn't, you saved a migration.
## How to actually move
If you're trying to adopt agents, not just keep up with them, this sequence works. It's boring. It works.
Pick one outcome that already matters. Not a moonshot. Not a horizontal "agent platform" project. Something measurable that your business already cares about. Deflecting support tickets. Drafting first-pass legal review. Qualifying inbound leads. Generating monthly reports. The agent succeeds when that outcome moves. This becomes your eval target on day one.
The reason this step matters more than anything else is that it constrains every subsequent decision. With a specific outcome, the question of "which framework" stops being philosophical. You pick the one that ships your outcome fastest. The question of "which model" stops being a benchmark argument. You pick the one your evals say works on this specific job. The question of "do we need memory / subagents / a custom harness" stops being a thought experiment. You only add what your specific failure modes require. Teams that skip this step end up building horizontal platforms nobody asked for. Teams that take it seriously end up shipping a single narrow agent that pays for itself in a quarter, and that single shipped agent teaches them more about the field than two years of reading.
Set up tracing and evals before you ship anything. Pick Langfuse or LangSmith. Wire it up. Build a small golden dataset by hand if you have to. Fifty labeled examples is enough to start. You will not be able to improve what you can't measure. The cost of building this later is roughly 10x the cost of building it now.
Start with a single-agent loop. Pick LangGraph or Pydantic AI. Pick Claude Sonnet 4.6 or GPT-5 as the model. Give the agent three to seven well-designed tools. Give it the file system or a database as state. Ship to a small audience. Watch the traces.
Treat the agent as a product, not a project. It will fail in ways you didn't predict. Those failures are your roadmap. Build the regression set from real production traces. Every prompt change, every model swap, every tool change goes through evals before deployment. This is where most teams underinvest. This is where most reliability comes from.
Add scope only when you've earned it. Subagents come in when context is the bottleneck. Memory frameworks come in when single-window context can't hold what you need. Computer use or browser use come in when the underlying APIs really aren't there. Don't pre-architect these. Let the failure modes pull them in.
Pick boring infrastructure. MCP for tools. E2B or Browserbase for sandboxes. Postgres or whatever data store you already run for state. Your existing auth and observability stack. The exotic infra is rarely the win. The discipline is.
Watch your unit economics from day one. Per-action costs. Cache hit rates. Retry-loop costs. Model-call distribution. Agents look cheap in PoC and explode at 100x scale unless you instrument cost per outcome from the start. A $0.50/run PoC becomes $50K/month at moderate volume. Teams that don't see it coming get a CFO meeting they don't enjoy.
Re-evaluate models quarterly, not weekly. Lock in for a quarter. At the end of the quarter, run your eval suite against the current frontier and switch if the data says to switch. You get the upside of model improvement without the chaos of chasing every release.
## Reading the tide
Concrete tells that something is signal:
A respected engineering team writes a postmortem with numbers, not just adoption claims. It's a primitive (protocol, pattern, infra), not a wrapper or bundle. It interoperates with what you already run instead of replacing it. The pitch describes a failure mode it solves, not a capability it enables. It's been around long enough to have a "what didn't work" blog post written about it.
Concrete tells that something is noise:
Demo videos with no production case studies after thirty days. Benchmark leaps too clean to be real. Pitches that use "autonomous," "agent OS," or "build any agent" without qualification. Frameworks whose docs assume you'll throw away your existing tracing, auth, and config. Star counts rising fast without commits, releases, and contributors rising with them. Twitter velocity without GitHub velocity.
A useful weekly habit: reserve thirty minutes on Friday for the field. Read three things. Anthropic's engineering blog. Simon Willison's notes. Latent Space. Skim one or two postmortems if any landed. Skip everything else for the week. You will know the things that matter.
## What's worth watching
Things worth attention over the next two quarters, not because they're guaranteed wins, but because the "is this signal?" question hasn't fully resolved:
Replit Agent 4's parallel forking model. First serious attempt at "multiple agents working in parallel" that doesn't trip over shared state. If it holds up at scale, the orchestrator-subagent default could shift.
Outcome-based pricing maturity. Sierra and Harvey's revenue trajectories validate it inside narrow verticals. The question is whether it generalizes outside, or stays a vertical-only model.
Skills as a packaging layer. The proliferation of AGENTS.md and skills directories across GitHub suggests an emerging way to package agent capabilities. Whether it standardizes the way MCP did for tools is the open question.
Claude Code's April 2026 quality regression and its postmortem. An industry-leading agent shipped a 47% performance regression and got caught by users before internal monitoring caught it. That's a lesson about how immature production agent eval practices still are, even at the leaders. If this drives industry-wide investment in better online evals, the correction is healthy.
Voice as the default support surface. Sierra's voice channel surpassed text in late 2025. If that pattern holds across other verticals, the design constraints (latency, interruption, real-time tool use) become first-order, and a lot of current architectures need rework.
Open-model agent capability closing the gap. DeepSeek-V3.2 with native thinking-into-tool-use. Qwen 3.6. The broader open landscape. Cost-performance for narrow agent tasks is shifting. The closed-source default isn't permanent.
Each of these has a clear "what would I need to see in six months to believe it" answer. That's the test. Track the answer, not the announcements.
## The unconventional bet
Every framework you don't adopt is a migration you don't owe. Every benchmark you don't chase is a quarter of focus you keep. The companies winning this cycle (Sierra, Harvey, Cursor in their respective domains) picked narrow targets, built boring discipline, and let the field's noise pass them by.
The conventional path was: pick a stack, master it for years, climb a ladder. That worked when the stack was stable for a decade. The stack now changes every quarter. The people winning stopped optimizing for stack mastery and started optimizing for taste, primitives, and ship velocity. They build small things in public. They learn by shipping. They get pulled into rooms by what they've already made. The credential is the artifact.
Sit with that for a second, because it's the actual point of this whole piece. Most of us were raised on a model of work that assumed the world held still long enough for credentials to compound. You went to school. You got the degree. You climbed the ladder. Two years here, three years there, and slowly the resume turned into something that opened doors. That whole machine assumed a stable industry on the other side of it.
The agent space has no stable other side right now. The companies you might want to work for are six months old. The frameworks they're built on are eighteen months old. The protocols underneath them are two years old. Half the most-cited posts in the field were written by people who weren't in the field three years ago. There is no ladder to climb because the building keeps changing floors. What's left, when the ladder doesn't work, is the much older method: make a thing, put it on the internet, let the work introduce you. It's the unconventional path because it ignores the credentialing system. It's also the only one that compounds in a moving field.
This is what the era looks like from inside. Even the giants are iterating in public, shipping regressions, writing postmortems, patching live. The teams shipping the most interesting things this year include people who weren't in the field eighteen months ago. Non-coders are pairing with agents and shipping real software. PhDs are getting outpaced by builders who picked the right primitives and started swinging. The gates are open. Most people are still trying to find the application form.
The skill you actually need to develop right now is not "agents." It's the discipline of figuring out which work compounds in a field where the surface keeps changing. Context engineering compounds. Tool design compounds. The orchestrator-subagent pattern compounds. Eval discipline compounds. The harness mindset compounds. Knowing the API of the framework that launched on Tuesday does not. Once you can tell those apart, the weekly launch tide stops feeling like pressure and starts feeling like noise you can ignore.
You don't need to learn everything. You need to learn the things that compound and skip the things that don't. Pick one outcome. Wire up tracing and evals before you ship. Use LangGraph or your team's equivalent. Use MCP. Sandbox your runtime. Default to single-agent. Add scope when failure modes pull it in. Re-evaluate models quarterly. Read three things on Fridays.
That's the playbook. The rest is taste, ship velocity, and the patience to not chase what doesn't matter. Build things. Put them on the internet. The era rewards people who make the thing more than people who can describe the thing. There has never been a better window to be the one making.
## 相关链接
- [Rohit](https://x.com/rohit4verse)
- [@rohit4verse](https://x.com/rohit4verse)
- [1.3M](https://x.com/rohit4verse/status/2049548305408131349/analytics)
- [$50K](https://x.com/search?q=%2450K&src=cashtag_click)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:56 AM · Apr 30, 2026](https://x.com/rohit4verse/status/2049548305408131349)
- [1.3M Views](https://x.com/rohit4verse/status/2049548305408131349/analytics)
- [View quotes](https://x.com/rohit4verse/status/2049548305408131349/quotes)
---
*导出时间: 2026/5/1 21:38:43*
---
## 中文翻译
# 2026年 AI Agent 领域：学什么、做什么、忽略什么
**作者**: Rohit
**日期**: 2026-04-29T17:56:09.000Z
**来源**: [https://x.com/rohit4verse/status/2049548305408131349](https://x.com/rohit4verse/status/2049548305408131349)
---
每天都有新框架、新基准、新“10倍效率”的产品发布。问题不再是“我怎么跟上”，而是：这里哪些才是真正的信号，哪些只是披着紧急外衣的噪音。
每条路线图在发布一个月后就会过时。你上季度精通的框架现在成了遗产。你优化的基准被刷榜并取代了。我们过去习惯于遵循传统路径：包含主题和层级的技术栈、一系列工作和任期、缓慢的攀升。AI 重写了这块画布。任何拥有正确提示词和品味的人，现在都能交付过去需要两年经验的工程师一个冲刺周期才能完成的工作。
专业能力依然重要。没有什么能取代目睹系统崩溃、凌晨2点调试内存泄漏、坚持选择无聊方案而非聪明方案并被证明正确的经验。这种品味会复利增长。不再像过去那样复利增长的东西是：了解本周框架的 API 表面。六个月后它就会变样。两年后获胜的人早早选择了持久的原语，并任由其他事物从身边掠过。
我在这个领域花了两年时间构建产品，拿到了多个超过 25 万美元的录用通知，现在在一家处于隐身模式的公司负责技术工作。如果有人问“我现在到底应该关注什么”，我会把这篇内容发给他。
这不是路线图。Agent 领域还没有终点。大实验室正在公开迭代，向数百万用户发布回退版本，撰写事后分析，进行热修复。如果 Claude Code 背后的团队发布了 47% 的性能回退却直到用户社区发现才察觉，那么认为这背后有一张稳定地图的想法简直是天方夜谭。每个人都在摸索。初创公司之所以蓬勃发展，是因为巨头们也不知道答案。非程序员正与 Agent 结对，在周五交付周二机器学习博士还声称不可能的东西。
这一刻最有趣的地方在于它如何改变了关于“资历”的问题。传统路径让你优化资历：学位、初级职位、高级职位、专家职位、缓慢的职级积累。当脚下的领域不移动时，这是有意义的。现在，这个领域在所有人脚下同样移动。一个 22 岁在公开场合发布 Agent 演示的年轻人和一个 35 岁的高级工程师之间的区别，不再是十年的技术栈积累。那个 22 岁的年轻人拥有和资深工程师一样的空白画布，对他们来说能产生复利的是交付意愿，加上那一小部分不会在一个季度内过时的原语。
这就是整篇文章立论的基础。接下来的内容提供了一种思维方式，帮助你判断哪些原语值得你关注，哪些发布可以任其掠过。选择适合你的。忽略不适合的。
## 真正有效的过滤器
你无法跟上每周的发布速度。你也不应该尝试。你需要的是一个过滤器，而不是信息流。
过去 18 个月里，以下五个测试经受住了考验。在让新发布的内容接触你的技术栈之前，先用它们过滤一遍。
**两年后这还有意义吗？** 如果它是前沿模型的封装、一个 CLI 标志，或者是“Devin 但用于 X”，答案几乎总是“不”。如果它是原语（协议、内存模式、沙箱方法），答案更多是“是”。封装的半衰期很短。原语的半衰期是以年计的。
**你尊重的人是否在其之上构建了真实的东西并诚实地记录了它？** 营销帖子不算。事后分析才算。一篇题为“我们在生产环境尝试了 X，以下是哪里出错了”的博客，价值抵得上十个发布公告。这个领域真正的好信号总是由那些为此牺牲过一个周末的人写出来的。
**采用它是否要求你丢弃现有的追踪、重试、配置和认证？** 如果是，它就是一个试图成为平台的框架。“试图成为平台的框架”死亡率高达 90%。好的原语能插入你现有的系统，而无需强制迁移。
**跳过它六个月的成本是什么？** 对于大多数发布，答案是什么都没有。六个月后你会知道得更多。胜出的版本会更清晰。这就是那个能让你毫无焦虑地跳过 90% 的发布的测试，也是大多数人拒绝运行的测试，因为跳过感觉像落后。其实不然。
**你能衡量它是否真的对你的 Agent 有帮助吗？** 如果你不能衡量，你就是在瞎猜。没有评估的团队靠直觉运行，发布回退版本。拥有评估的团队可以让数据告诉他们，本周在他们的特定工作负载上是 GPT-5.5 还是 Opus 4.7 赢了。
如果你要从整篇文章中采纳一个习惯，请采纳这个：当有新东西发布时，写下你在六个月内需要看到什么才会相信它很重要。然后回来检查。大多数时候，问题会自动解开，而你会把注意力集中在能产生复利的事情上。
这些测试背后的技能比它们任何一项都更难命名。那就是愿意对你不选择的事物表现得“不酷”。本周在 Hacker News 上爆火的框架会有整整 14 天的啦啦队，而且他们听起来都很聪明。六个月后，这些框架中有一半无人维护，啦啦队们已经转移阵地。那些没有参与的人把注意力留给了那些在发布炒作褪去后经受住“无聊”测试的事物。这种姿态——克制、观察、说“我六个月后就知道了”——才是该领域真正的专业技能。每个人都能看发布会。几乎没有人擅长不对它们做出反应。
## 学什么
概念。模式。事物的形状。这些是能带来复利回报的想法。它们在模型替换、框架更替、范式转移中幸存下来。深刻理解它们，你就能在一个周末内学会任何新工具。跳过它们，你将永远在重新学习表面的机制。
**上下文工程**
过去两年最重要的改名是“提示工程”变成了“上下文工程”。这种转变是真实的，而非表面的。
模型不再是你为其编写巧妙指令的东西。它是你在每一步为其组装工作上下文的东西。那个上下文是系统指令、工具架构、检索到的文档、先前的工具输出、草稿板状态和压缩历史记录的总和。Agent 的行为是你放入窗口中的内容的涌现属性。
请内化这一点：上下文即状态。每一个无关噪声的 token 都会消耗你的推理质量。上下文腐烂是真实的生产故障。在一个十步任务的第八步，原始目标可能被工具输出掩埋。那些交付可靠 Agent 的团队会主动总结、压缩、修剪。他们对工具描述进行版本控制。他们缓存静态部分，拒绝缓存变化的部分。他们像经验丰富的工程师思考 RAM 那样思考上下文窗口。
一个具体感受的方法：取任何生产环境的 Agent 并开启完整的追踪日志。看第一步的上下文。看第七步的上下文。数一数有多少 token 仍在发挥作用。第一次做这件事时，你会感到尴尬。然后你会去修复它，而同一个 Agent 将在没有任何模型或提示更改的情况下变得明显更可靠。
如果你只读一样东西，就读 Anthropic 的《AI Agent 的有效上下文工程》。然后读他们的多 Agent 研究事后分析，其中量化了扩展规模时上下文隔离的重要性。
**工具设计**
工具是 Agent 与你的业务相遇的地方。模型根据名称和描述选择工具。模型根据错误消息重试。工具的契约是否匹配 LLM 擅长表达的内容，决定了模型的成败。
五到十个命名良好的工具胜过二十个平庸的工具。工具名称应该像英语动词短语一样阅读。描述应包括何时使用工具，何时不使用。错误消息应该是模型可以据此行动的反馈。“超过最大 token 数 500，请先尝试总结”比“错误：400 错误请求”好无数倍。公开研究中的一个团队报告说，仅重写错误消息就减少了 40% 的重试循环。
Anthropic 的《为 Agent 编写工具》是正确的起点。之后，给你的工具加上检测并查看实际的调用模式。Agent 可靠性最大的胜利几乎总是在工具端。人们不断调整提示词，却忽略了实际杠杆所在的领域。
**编排器-子 Agent 模式**
2024 年和 2025 年的多 Agent 争论以每个人现在都在发布的综合方案告终。朴素的多 Agent 系统，即多个 Agent 并行写入共享状态，会灾难性地失败，因为错误会复合。单 Agent 循环的扩展超出了你的预期。有一种多 Agent 形状在生产中有效：一个编排器 Agent 将范围狭窄的只读任务委托给隔离的子 Agent，然后综合它们的结果。
这就是 Anthropic 研究系统的工作方式。这就是 Claude Code 子 Agent 的工作方式。这是 Spring AI 和大多数生产框架现在标准化的模式。子 Agent 获得小的、专注的上下文。它们不能改变共享状态。编排器拥有写入权。
Cognition 的《不要构建多 Agent》文章和 Anthropic 的《我们如何构建我们的多 Agent 研究系统》看起来截然相反，但实际上是用不同的词汇表达同一件事。两篇都读一下。
默认使用单 Agent。只有当单 Agent 碰到真正的墙时——上下文窗口压力、顺序工具调用的延迟，或确实受益于专注上下文的任务异构性——才求助于编排器-子 Agent。在你感到痛苦之前构建这个，会交付你不需要的复杂性。
**评估和黄金数据集**
每个交付可靠 Agent 的团队都有评估。没有的团队就没有。这是该领域杠杆率最高的习惯，也是我在考察过的每家公司中看到投资最不足的地方。
有效的方法：收集你的生产追踪，标记失败，将其视为回归集。每当有新的失败发布时，就添加进去。对主观部分使用 LLM 作为裁判，其余部分使用精确匹配或程序化检查。在任何提示、模型或工具更改之前运行套件。Spotify 的工程博客报道，他们的裁判层在 Agent 输出发布前否决了约 25%。没有它，四分之一的不良结果会到达用户那里。
让这一点的思维模型固化下来：评估是一个单元测试，在其他一切都发生变化时保持 Agent 的诚实。模型获得了新版本。框架发布了破坏性更改。供应商弃用了端点。你的评估是唯一能告诉你 Agent 是否仍在工作的东西。没有它们，你编写的系统的正确性取决于一个移动目标的善意。
评估框架很好。没有一个构成瓶颈。瓶颈是首先拥有一个标记的集合。在第一天就构建它，在你扩展任何东西之前。前 50 个例子可以在一个下午手动标记。没有任何借口。
**文件系统即状态与思考-行动-观察循环**
对于任何从事真正的多步工作的 Agent，持久的架构是：思考、行动、观察、重复。文件系统或结构化存储作为真理之源。每一个操作都被记录并可重放。Claude Code、Cursor、Devin、Aider、OpenHands、goose。它们都因为一个原因而收敛于此。
模型是无状态的。工具架必须是有状态的。文件系统是每个开发者都已经理解的有状态原语。一旦你接受这个框架，整个工具架纪律（检查点、可恢复性、子 Agent 验证、沙箱执行）就会从认真对待这一模式中自然产生。
这更深层次地教会了你：在任何值得计算费用的生产 Agent 中，工具架完成的工作比模型多。模型选择下一个行动。工具架验证它，在沙箱中运行它，捕获输出，决定反馈什么，决定何时停止，决定何时检查点，决定何时生成子 Agent。将模型换为另一个质量相似的模型，好的工具架依然能交付。将工具架换为更差的，世界上最好的模型仍然会产生一个随机忘记自己在做什么的 Agent。
如果你正在构建比单次工具调用更复杂的东西，工具架是你应该花时间的地方。模型只是其中的一个组件。
**概念上的 MCP**
不要只学习如何调用 MCP 服务器。要学习这个模型。Agent 能力、工具和资源之间的清晰分离，底层具有可扩展的认证和传输机制。一旦你理解了它，你看到的每一个其他“Agent 集成框架”看起来都像是 MCP 的更差版本，你会节省评估每一个的时间。
Linux 基金会现在管理它。每个主要模型提供商都支持它。“AI 界的 USB-C”这个比喻现在比讽刺更准确。
**作为原语的沙箱**
每个生产编码 Agent 都在沙箱中运行。每个浏览器 Agent 都遭受过间接提示注入。每个多租户 Agent 在某个时刻都发布过权限范围界定错误。将沙箱视为原语基础设施，而不是客户要求时才添加的功能。
学习基础知识。进程隔离。网络出口控制。密钥范围界定。Agent 与工具之间的认证边界。在客户安全审查之后才加上这些功能的团队会丢掉生意。从一开始就构建这些功能的团队可以轻松通过企业采购。
## 用什么构建
具体选择，2026 年 4 月。这些会变化，但很慢。在这里选择无聊的。
**编排**
LangGraph 是生产环境的默认选择。大约三分之一运行 Agent 的大公司使用它。其抽象与 Agent 系统的真实形状相匹配：类型化状态、条件边、持久工作流、人工检查点。缺点是冗长。优点是冗长匹配了 Agent 进入生产环境后你实际需要控制的东西。
如果你生活在 TypeScript 世界，Mastra 是事实上的选择。该生态系统中最清晰的思维模型。
如果你的团队喜欢 Pydantic 并希望类型安全成为一等公民，Pydantic AI 是一个合理的绿地选择。它在 2025 年底达到 v1.0，势头是真实的。
对于提供商原生工作（计算机使用、语音、实时），在 LangGraph 节点内使用 Claude Agent SDK 或 OpenAI Agents SDK。不要试图让任何一个成为异构系统的顶级编排器。它们为自己的赛道进行了优化。
**协议层**
MCP，绝对的。将你的工具集成构建为 MCP 服务器。以同样的方式消费外部集成。注册表已经跨过了那个点，你几乎总是能在需要构建之前找到一个服务器。在 2026 年编写自定义工具管道纯粹是白交税。
**记忆**
根据自主级别选择，而不是根据炒作。
用于聊天式个性化的 Mem0。用户偏好、轻度历史。Zep 用于状态演变且需要实体跟踪的生产对话系统。Letta 用于 Agent 在数天或数周的工作中保持连贯性。大多数团队不需要这个。需要的团队，恰恰需要这个。
错误是在遇到记忆问题之前就选择记忆框架。从你的上下文窗口能容纳的任何东西加上向量存储开始。只有当你能明确它解决了什么失败模式时，才添加记忆系统。
**可观察性和评估**
Langfuse 是开源软件默认选择。可自托管，MIT 许可，涵盖追踪、提示版本控制和基本的 LLM 作为裁判的评估。如果你已经是 LangChain 商店，L