AI Agent 学习指南：2026 年应学什么、构建什么以及忽略什么

✍ Rohit🕐 2026-04-30📦 30.4 KB 🟢 已读 𝕏 文章列表

本文针对 AI 领域快速迭代带来的焦虑，提出了一套判断技术价值的筛选标准，建议关注具有长期复利的“原始概念”而非短暂的封装框架。文章重点探讨了“上下文工程”的演变及“工具设计”的重要性，强调在混乱的生态中应保持耐心，注重核心模式与可衡量性，而非盲目追逐每周的新框架。

# 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) --- ![Image](/doc/1298/image/img_33f747fa4bc9.jpg) 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) - [122K](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) - [122.7K Views](https://x.com/rohit4verse/status/2049548305408131349/analytics) - [View quotes](https://x.com/rohit4verse/status/2049548305408131349/quotes) --- *导出时间: 2026/4/30 09:25:52* --- --- ## 中文翻译 # AI 智能体在 2026 年该学什么、构建什么、跳过什么 **作者**：Rohit **日期**：2026-04-29T17:56:09.000Z **来源**：[https://x.com/rohit4verse/status/2049548305408131349](https://x.com/rohit4verse/status/2049548305408131349) --- ![Image](/doc/1298/image/img_33f747fa4bc9.jpg) 每天都有新的框架、新的基准测试、新的“10倍效率”产品发布。问题不再是“我该如何跟上节奏”。而是：这里到底什么是真正的信号，什么只是披着紧迫外衣的噪音。每个路线图在发布一个月后就会过时。你上一季度精通的框架现在已成“遗产”。你优化的那个基准测试已经被攻克，并被取代。我们被训练去遵循一条传统的路径：一个包含主题和级别的技术栈，一系列工作和任期，一次缓慢的攀爬。AI 重写了这张画布。任何拥有合适提示词和品味的人，现在都能交付过去需要一名两年经验工程师一个冲刺才能完成的工作。专业能力依然重要。没有什么能取代亲眼见证系统崩溃的经验，取代凌晨2点调试内存泄漏的经历，取代坚持无聊但正确选择而非聪明但危险选择的争论并最终被证明是对的。这种品味是会复利的。不再像以前那样能复利的是：了解本周那个框架的 API 表面。六个月后它就会变样。两年后能赢的人，很早就选择了持久的基础原语，而让其他的从身边溜走。我在这个领域深耕了两年，拿到了多个年薪超过 25 万美元的 Offer，现在一家处于隐身模式的公司负责技术工作。如果有人问“我现在到底应该关注什么”，我会发给他这些内容。这不是一张路线图。智能体领域目前还没有终点。大厂正在公开迭代，向数百万用户发布性能回退版本，写复盘文章，打热补丁。如果 Claude Code 背后的团队发布了一个 47% 的性能回退，并且在用户社区发现后才意识到，那么认为这背后有一张稳定地图的想法纯属虚构。每个人都在摸索。初创公司之所以蓬勃发展，是因为巨头们也不知道答案。非程序员正在与智能体结对编程，在周五交付的东西，机器学习博士在周二还称是不可能的。这一刻最有趣的地方在于它对“资历”这个问题的影响。传统路径优化的是你的资历：学位、初级职位、高级职位、专家职位，等级的缓慢积累。当脚下的领域不移动时，这是合理的。现在这个领域在每个人脚下同等地移动。一个 22 岁在公开场合发布智能体演示的年轻人和一个 35 岁的高级工程师之间的区别，不再是十年积累的栈掌握程度。22 岁的年轻人拥有与高级工程师相同的空白画布，对两者来说能产生复利的是交付的意愿，加上那些在一个季度内不会过时的原语列表。这就是整篇文章赖以构建的思维转换。接下来是一种思考方式，用于判断哪些原语值得你关注，哪些发布可以忽略。选择适合你的。留下不适合的。 ## 真正有效的过滤器你无法跟上每周的发布速度。你不应该尝试。你需要的是一个过滤器，而不是信息流。在过去 18 个月里，有五个测试经得起考验。在让任何新发布的技术接触你的技术栈之前，先用这些测试过滤一遍。 **这在两年后还重要吗？** 如果它是围绕前沿模型的封装、一个 CLI 标志，或者是“Devin 但用于 X”，答案几乎总是“否”。如果它是一个原语（一种协议、一种内存模式、一种沙箱方法），答案更多时候是“是”。封装的半衰期很短。原语的半衰期是以年计的。 **你尊重的人有没有基于它构建了真实的东西并诚实地撰文记录？** 营销文章不算。复盘文章才算。一篇标题为“我们在生产环境中尝试了 X，以下是崩溃原因”的博客，价值十倍于发布公告。这个领域里好的信号总是由那些为此牺牲过周末的人写出来的。 **采用它是否需要你抛弃现有的追踪、重试、配置和认证？** 如果是，那就是一个试图成为平台的框架。试图成为平台的框架有 90% 的死亡率。好的原语可以嵌入到你现有的系统中，而无需强制迁移。 **跳过它六个月的成本是什么？** 对于大多数发布，答案是什么成本也没有。六个月后你会知道得更多。胜出的版本也会更清晰。这是让你毫无焦虑地跳过 90% 的发布的测试，也是大多数人拒绝运行的测试，因为跳过感觉像落后。其实不然。 **你能否衡量它是否真的对你的智能体有帮助？** 如果你不能，你就是在瞎猜。没有评估的团队靠“直觉”运行，并发布回退版本。有评估的团队可以让数据告诉他们，本周在他们的特定工作负载上是 GPT-5.5 还是 Opus 4.7 赢了。如果你要从整篇文章中采纳一个习惯，就选这个：当有新东西发布时，写下你在六个月后需要看到什么才能相信它很重要。然后再回来检查。大多数时候，问题会自动解决，而你会把注意力花在能产生复利的事情上。这些测试背后的技能比任何测试都更难命名。那就是对于你不捡起来的东西，要甘愿显得“不酷”。本周在 Hacker News 上爆火的框架会有十四天的欢呼大军，他们听起来都很聪明。六个月后，这些框架中有一半无人维护，啦啦队们已经转移阵地。那些没有参与的人节省了注意力，留给那些在发布炒作过去后依然能经受住“无聊”考验的事物。这种姿态——按兵不动、观察、说“我六个月后再知道”——是这个领域真正的职业技能。每个人都能阅读发布公告。几乎没有人擅长不对它们做出反应。 ## 学什么概念。模式。事物的形态。这些是能带来复利回报的思想。它们经得起模型替换、框架替换、范式转换。深入理解它们，你就能在一个周末内掌握任何新工具。跳过它们，你将永远在重新学习表面机制。 **上下文工程** 过去两年最重要的改名是将“提示词工程”变为“上下文工程”。这种转变是真实的，而非表面功夫。模型不再是你为其编写巧妙指令的东西。它是你在每一步为其组装工作上下文的东西。那个上下文是系统指令、工具模式、检索到的文档、先前的工具输出、草稿本状态和压缩历史的混合体。智能体的行为是你放入窗口中的内容的涌现属性。请在内心消化这一点：上下文即状态。每一个无关噪音的 Token 都会消耗你的推理质量。上下文腐烂是真实的生产故障。在一个十步任务的第八步，最初的目标可能已经被工具输出掩埋。那些交付可靠智能体的团队会主动总结、压缩和修剪。他们对工具描述进行版本控制。他们缓存静态部分，拒绝缓存变化的部分。他们像经验丰富的工程师思考 RAM 那样思考上下文窗口。一个具体的感知方法：拿任何一个生产中的智能体，开启全量追踪日志。看第一步的上下文。看第七步的上下文。数数有多少 Token 还在发挥作用。第一次做这件事时，你会感到尴尬。然后你会去修复它，同一个智能体会在没有任何模型或提示词更改的情况下，明显变得更可靠。如果只读一篇关于这个的文章，就读 Anthropic 的《Effective Context Engineering for AI Agents》（AI 智能体的有效上下文工程）。然后读他们的多智能体研究复盘，其中列出了数据，说明一旦扩大规模，上下文隔离有多重要。 **工具设计** 工具是智能体与你业务交汇的地方。模型根据名称和描述选择工具。模型根据错误信息进行重试。工具的契约是否与 LLM 擅长表达的内容相匹配，决定了模型的成败。 5 到 10 个命名得当的工具胜过 20 个平庸的工具。工具名称应该读起来像英语动词短语。描述应包含何时使用以及何时不使用该工具。错误信息应该是模型可以据此行动的反馈。“超过最大 Token 数 500，请先尝试总结”比“错误：400 错误请求”好太多了。公共研究中的一个团队报告说，仅重写错误信息就减少了 40% 的重试循环。 Anthropic 的《Writing tools for agents》（为智能体编写工具）是正确的起点。之后，对你自己的工具进行插桩，查看实际的调用模式。智能体可靠性的最大提升几乎总是在工具侧。人们不断调整提示词，却忽略了真正杠杆所在的地方。 **编排器-子智能体模式** 2024 年和 2025 年的多智能体辩论以一个综合方案结束，现在大家都在交付这个。天真的多智能体系统（多个智能体并行写入共享状态）会灾难性地失败，因为错误会复合。单智能体循环的扩展能力超乎你的预期。只有一种多智能体形态在生产中有效：一个编排器智能体将范围狭窄的只读任务委托给隔离的子智能体，然后综合它们的结果。这就是 Anthropic 研究系统的工作方式。这也是 Claude Code 子智能体的工作方式。这是 Spring AI 和大多数生产框架现在标准化的模式。子智能体获得小的、集中的上下文。它们不能改变共享状态。编排器负责写入。 Cognition 的《Don't Build Multi-Agents》（不要构建多智能体）文章和 Anthropic 的《How we built our multi-agent research system》（我们如何构建多智能体研究系统）看起来像是对立的，实际上是在用不同的词汇说同一件事。两篇都读。默认单智能体。只有当单智能体撞上真正的墙时（上下文窗口压力、顺序工具调用的延迟、或确实受益于集中上下文的任务异构性），才求助于编排器-子智能体模式。在感到痛苦之前构建这个，会交付你不需要的复杂性。 **评估和黄金数据集** 每个交付可靠智能体的团队都有评估。每个没有的团队，都没有。这是该领域杠杆率最高的习惯，也是我在每家考察过的公司中看到的最被低估的投资。有效的方法：收集你的生产追踪记录，标记失败案例，将其视为回归测试集。每当有新的失败发布时，就添加进去。对于主观部分使用 LLM-as-judge（大模型做评判），其余部分使用精确匹配或程序化检查。在任何提示词、模型或工具更改之前运行该套件。Spotify 的工程博客报道，他们的评判层会在结果发布给用户之前否决约 25% 的智能体输出。没有它，四分之一的坏结果就会到达用户手中。让这个习惯保持下去的心智模型是：评估是一种单元测试，在其他一切都在变化时，它负责让智能体保持诚实。模型获得了新版本。框架发布了破坏性更改。供应商弃用了某个端点。你的评估是唯一能告诉你你的智能体是否还在做本职工作的东西。没有它们，你就是在编写一个正确性依赖于移动目标善意的系统。评估框架可以，但没有一个是瓶颈。瓶颈在于首先拥有一个标记好的数据集。第一天就构建它，在你扩展任何东西之前。前 50 个例子可以在一个下午手动标记。没有借口。 **文件系统即状态与思考-行动-观察循环** 对于任何做真实多步工作的智能体，持久的架构是：思考、行动、观察、重复。文件系统或结构化存储作为真相来源。每个行动都被记录并可重放。Claude Code、Cursor、Devin、Aider、OpenHands、goose。它们都因为某种原因收敛于此。模型是无状态的。控制架必须是有状态的。文件系统是每个开发者已经理解的有状态原语。一旦你接受这个框架，整个控制架的纪律（检查点、可恢复性、子智能体验证、沙箱执行）就会源于对这个模式的认真对待。这件事更深层地教会了你：在任何值得计算费的生产级智能体中，控制架做的活比模型多。模型选择下一个行动。控制架验证它，在沙箱中运行它，捕获输出，决定反馈什么，决定何时停止，决定何时检查点，决定何时生成子智能体。把模型换成另一个质量相似的模型，好的控制架依然能交付。把控制架换成更差的，世界上最好的模型仍然会产生一个随机忘记自己在做什么的智能体。如果你正在构建任何比单次工具调用更复杂的东西，你应该把时间花在控制架上。模型只是其中的一个组件。 **从概念上理解 MCP** 不要只学习如何调用 MCP 服务器。要学习其模式。智能体能力、工具和资源之间的清晰分离，底层具有可扩展的认证和传输机制。一旦你理解了它，你看到的每一个其他“智能体集成框架”看起来都会像是 MCP 的更糟糕版本，你将节省评估每一个的时间。 Linux Foundation 现在管理它。每个主要模型提供商都支持它。“AI 的 USB-C”这个比喻现在比讽刺更准确。 **将沙箱视为原语** 每个生产级编码智能体都在沙箱中运行。每个浏览器智能体都遭受过间接提示注入。每个多租户智能体在某个时刻都发布过权限范围错误。将沙箱视为原语基础设施，而不是当客户要求时才添加的功能。学习基础。进程隔离。网络出口控制。密钥范围。智能体与工具之间的认证边界。那些在客户安全审查后才加上这些功能的团队会丢掉生意。那些从第一周就构建进去的团队可以毫不费力地通过企业采购。 ## 用什么构建具体选择，2026 年 4 月。这些会变化，但很慢。在这里选择无聊的东西。 **编排** LangGraph 是生产默认选择。大约三分之一的运行智能体的大公司使用它。其抽象概念符合智能体系统的真实形状：类型化状态、条件边、持久工作流、人工在环检查点。缺点是冗长。优点是这种冗长符合智能体在生产中实际需要控制的内容。如果你生活在 TypeScript 世界，Mastra 是事实上的选择。该生态系统中思维模型最干净的一个。如果你的团队喜欢 Pydantic 并且希望类型安全作为一等公民，Pydantic AI 是一个合理的绿地选择。它在 2025 年底达到 v1.0，势头很真实。对于提供商原生工作（计算机使用、语音、实时），在你的 LangGraph 节点内使用 Claude Agent SDK 或 OpenAI Agents SDK。不要试图让其中任何一个成为异构系统的顶层编排器。它们都在各自的跑道上进行了优化。 **协议层** MCP，毫无疑问。将你的工具集成构建为 MCP 服务器。以同样的方式消费外部集成。注册表已经过了这样一个临界点：你几乎总能找到一个服务器，而无需自己构建。在 2026 年编写自定义工具管道是在毫无意义地交税。 **记忆** 根据自主级别选择，而不是根据炒作。 Mem0 用于聊天风格的个性化。用户偏好、轻量历史。Zep 用于状态会进化的生产对话系统，并且你需要实体跟踪。Letta 用于智能体在数天或数周的工作中保持连贯性。大多数团队不需要这个。需要的团队，恰恰需要的就是这个。错误是在你有记忆问题之前就去寻找记忆框架。从你的上下文窗口能容纳的任何东西加上向量存储开始。只有当你能明确指出它解决的失败模式时，再添加记忆系统。 **可观测性和评估** Langfuse 是开源默认选择。可自托管，MIT 许可，涵盖追踪、提示词版本控制和基础 LLM-as-judge 评估。如果你已经是 LangChain 商店，LangSmith 集成得更紧密。Braintrust 是具有严格比较的研究风格评估工作流的正确选择。如果你需要混合技术栈中供应商无关的 OpenTelemetry 插桩，OpenLLMetry / Traceloop 是答案。你需要追踪和评估。追踪回答“智能体实际上做了什么？”评估回答“智能体比昨天好还是坏？”没有两者不要交付。盲目运行的成本是第一天正确接入它们的成本的十倍。 **运行时和沙箱** E2B 用于通用沙箱代码执行。Browserbase（配合 Stagehand）用于浏览器自动化。当你需要真正的操作系统级桌面控制时，使用 Anthropic Computer Use。Modal 用于短时突发。永远不要运行无沙箱的代码执行。生产环境中的单个提示注入智能体的爆炸半径是一个你不想讲述的故事。 **模型** 追逐基准测试是令人疲惫的，而且大多没有帮助。实际上，在 2026 年 4 月： Claude Opus 4.7 和 Sonnet 4.6 用于可靠的工具使用、多步连贯性和优雅的故障恢复。对于大多数工作负载，Sonnet 是性价比的甜蜜点。当你需要最强的 CLI/终端推理或你生活在 OpenAI 基础设施中时，使用 GPT-5.4 和 5.5。Gemini 2.5 和 3 用于长上下文为主或多模态为主的工作。当成本比顶级性能更重要时，特别是对于狭窄定义明确的任务，使用 DeepSeek-V3.2 或 Qwen 3.6。将模型视为可互换的。如果你的智能体只能用一种模型工作，这是一种坏味道，而不是护城河。使用评估来决定部署什么。每季度重新评估，而不是每周。 ## 跳过什么你会被告知要学习并使用所有这些东西。你不需要。跳过的成本很低。节省的时间很大。 **生产中的 AutoGen 和 AG2。** 微软的框架已移至社区维护，发布停滞，抽象概念不符合生产团队的实际需求。适合学术探索。不要基于它构建产品。 **新生产构建中的 CrewAI。** 它到处都是，因为它很容易演示。构建真实系统的工程师已经离开了它。如果你愿意，可以用于原型。不要依赖它。 **Microsoft Semantic Kernel，除非你被锁定在微软企业栈中，并且你的买家在乎这一点。** 这不是生态系统的发展方向。 **DSPy，除非你专门大规模优化提示词程序。** 哲学上有价值，受众小众。不是通用的智能体框架。不要把它当作一个来选。 **作为架构选择的独立代码编写智能体。** 代码即行动是有趣的研究。它还不是生产默认模式，你会陷入工具和安全的战斗，而你的竞争对手没有这些麻烦。 **“自主智能体”推销。** AutoGPT 和 BabyAGI 家谱在产品形式上已经死亡。行业诚实的框架是“智能体工程”：受监督、有边界、经过评估。任何在 2026 年仍在销售即弃即忘的自主智能体的人，卖给你的是 2023 年的货。 **智能体应用商店和市场。** 从 2023 年就开始承诺，从未实现企业吸引力。企业不购买通用的预构建智能体。他们购买与结果挂钩的垂直智能体，或者自己构建。不要围绕应用商店的梦想构建你的业务。 **作为客户的横向“构建任何智能体”企业平台（Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio 级别）。** 它们最终会有用。目前它们令人困惑，发布缓慢，而且“购买与自建”的数学计算仍然倾向于自己构建狭窄的智能体或购买垂直智能体。Salesforce Agentforce 和 ServiceNow Now Assist 是例外，因为它们通过嵌入你已经使用的工作流系统而获胜。 **追逐 SWE-bench 和 OSWorld 排行榜。** 伯克利研究人员在 2025 年记录了几乎每一个公共基准测试都可以在不解决底层任务的情况下被攻克。团队现在使用 Terminal-Bench 2.0 和他们自己的内部评估作为真正的信号。默认对单数基准测试的飞跃持怀疑态度。 **天真的并行多智能体架构。** 五个智能体通过共享内存聊天在演示中看起来令人印象深刻，在生产中会分崩离析。如果你不能在餐巾纸上画出一个具有读/写边界的清晰编排器-子智能体图，就不要发布它。 **新智能体产品的按座席 SaaS 定价。** 市场已经转向基于结果和使用的定价。按座席定价会把钱留在桌子上，并向买家发出信号，表明你不相信自己的产品能交付结果。 **本周你在 Hacker News 上看到的下一个框架。** 等六个月。如果它仍然重要，显而易见。如果不重要，你省了一次迁移。 ## 如何实际行动如果你正在尝试采用智能体，而不仅仅是跟上它们，这个顺序很有效。它很无聊。它有效。 **选择一个已经重要的结果。** 不是登月计划。不是一个横向的“智能体平台”项目。你的业务已经关心的可衡量的东西。分流支持工单。起草第一遍法律审查。筛选入站线索。生成月度报告。当那个结果改善时，智能体就成功了。这成为你第一天的评估目标。这一步比其他任何步骤都重要的原因是，它限制了每一个后续决策。有了特定的结果，“哪个框架”的问题不再是哲学问题。你选择能最快交付你的结果的那个。“哪个模型”的问题不再是基准测试争论。你选择你的评估显示在这个特定工作上有效的那个。“我们需要记忆/子智能体/自定义控制架吗”的问题不再是思想实验。你只添加你的特定失败模式所需的东西。跳过这一步的团队最终会构建没人要求的横向平台。认真对待这一步的团队最终会交付一个单一狭窄的智能体，在一个季度内回本，而这单一交付的智能体教给他们的关于这个领域的知识，比两年的阅读还多。 **在发布任何东西之前设置追踪和评估。** 选择 Langfuse 或 LangSmith。连接起来。如果必须，手动构建一个小的黄金数据集。50 个标记的例子足以开始。你无法改善你无法衡量的东西。以后构建它的成本大约是现在的 10 倍。 **从单智能体循环开始。** 选择 LangGraph 或 Pydantic AI。选择 Claude Sonnet 4.6 或 GPT-5 作为模型。给智能体三到七个设计良好的工具。给它文件系统或数据库作为状态。向一小群人发布。观察追踪记录。 **将智能体视为产品，而不是项目。** 它会以你无法预测的方式失败。那些失败就是你的路线图。从真实的生产追踪记录构建回归集。每次提示词更改、模型交换、工具更改在部署前都要经过评估。这是大多数团队投资不足的地方。这是大多数可靠性的来源。 **只有在你赢得资格后才增加范围。** 当上下文成为瓶颈时，子智能体才会介入。当单窗口上下文无法容纳你需要的东西时，记忆框架才会介入。当底层 API 真的不存在时，计算机使用或浏览器使用才会介入。不要预先设计这些。让失败模式把它们拉进来。 **选择无聊的基础设施。** MCP 用于工具。E2B 或 Browserbase 用于沙箱。Postgres 或你已经在运行的任何数据存储用于状态。你现有的认证和可观测性技术栈。异国情调的基础设施很少是赢面。纪律才是。 **从第一天起关注你的单位经济。** 每次行动的成本。缓存命中率。重试循环成本。模型调用分布。智能体在概念验证（PoC）中看起来很便宜，除非你从一开始就检测每个结果的成本，否则在 100 倍规模下会爆炸。每次运行 0.50 美元的 PoC 在中等体量下变成每月 5 万美元。没有预见到这一点的团队会得到一次他们不喜欢的 CFO 会议。 **每季度重新评估模型，而不是每周。** 锁定一个季度。在季度末，对你的评估套件运行当前的前沿模型，如果数据说切换就切换。你获得了模型改进的好处，而没有追逐每次发布的混乱。 ## 读懂潮水某事是信号的具体迹象：一个受人尊敬的工程团队写了一篇带有数字的复盘文章，而不仅仅是采用声明。它是一个原语（协议、模式、基础设施），而不是封装或捆绑。它与您已经运行的东西互操作，而不是替换它。推销描述的是它解决的失败模式，而不是它启用的能力。它已经存在足够长的时间，以至于有人写了一篇关于“什么不起作用”的博客文章。某事是噪音的具体迹象：三十天后没有生产案例研究的演示视频。干净得不真实的基准测试飞跃。毫无保留地使用“自主”、“智能体操作系统”或“构建任何智能体”的推销。文档假设你会抛弃现有的追踪、认证和配置的框架。星数快速上升，但提交、发布和贡献者没有随之上升。Twitter 速度快，GitHub 速度慢。一个有用的每周习惯：每周五留出 30 分钟给这个领域。读三样东西。Anthropic 的工程博客。Simon Willison 的笔记。Latent Space。如果有的话，浏览一两篇复盘文章。本周跳过其他所有东西。你会知道重要的事情。 ## 什么值得关注未来两个季度值得关注的事情，不是因为有保证的赢面，而是因为“这是信号吗？”这个问题尚未完全解决： Replit Agent 4 的并行分叉模型。第一次严肃的“多个智能体并行工作”的尝试，没有被共享状态绊倒。如果它在规模上站得住脚，编排器-子智能体的默认可能会转移。基于结果的定价成熟度。Sierra 和 Harvey 的收入轨迹在狭窄的垂直领域验证了这一点。问题是它是否会推广到外部，还是只停留在垂直模式。技能作为包装层。GitHub 上 AGENTS.md 和技能目录的激增表明了一种封装智能体能力的新兴方式。它是否会像 MCP 对工具那样标准化，这是一个悬而未决的问题。 Claude Code 2026 年 4 月的质量回退及其复盘。一个行业领先的智能体发布了 47% 的性能回退，在内部监控发现之前被用户抓住了。这一课说明了，即使对于领导者，生产级智能体评估实践仍然多么不成熟。如果这推动了行业对更好的在线评估的投资，这种纠正是健康的。语音作为默认支持表面。Sierra 的语音频道在 2025 年底超过了文本。如果这种模式在其他垂直领域成立，设计约束（延迟、中断、实时工具使用）变得首要，许多当前的架构需要重做。开放模型智能体能力缩小差距。原生具有思考进工具使用的 DeepSeek-V3.2。Qwen 3.6。更广阔的开源景观。狭窄智能体任务的性价比正在转移。闭源默认不是永久的。每一个都有一个明确的“我需要在六个月内看到什么才能相信它”的答案。这就是测试。追踪答案，而不是公告。 ## 非常规的赌注每一个你不采用的框架都是你欠下的迁移。每一个你不追逐的基准测试都是你保持的一个季度的专注。在这个周期获胜的公司（Sierra、Harvey、Cursor 在各自的领域）选择了狭窄的目标，构建了无聊的纪律，让领域的噪音从身边溜走。传统路径是：选择一个技术栈，掌握它多年，爬梯子。当技术栈稳定十年时，这很有效。现在技术栈每季度都在变化。获胜的人不再优化对技术栈的掌握，开始优化品味、原语和交付速度。他们在公开场合构建小东西。他们通过交付来学习。他们因为已经制作的东西而被拉进房间。资历就是产物。坐下来想一想，因为这是整篇文章的真正重点。我们大多数人是基于一种工作模式长大的，该模式假设世界静止不动足够长的时间，让资历能够复利。你上学。你获得学位。你爬梯子。这里两年，那里三年，慢慢地简历变成了能开门的东西。整个机器假设另一边是一个稳定的行业。智能体领域目前没有稳定的一面。你可能想为之工作的公司只有六个月大。构建它们的框架有 18 个月大。它们底层的协议有两年大。该领域一半被引用最多的文章是由三年前不在该领域的人写的。没有梯子可以爬，因为建筑物一直在换楼层。当梯子不起作用时，剩下的就是更古老的方法：做一个东西，把它放在互联网上，让工作介绍你。这是非常规的路径，因为它忽略了认证系统。它也是在移动领域唯一能复利的路径。这是从内部看这个时代的样子。即使是巨头也在公开迭代，发布回退，写复盘，打热补丁。今年发布最有趣东西的团队包括 18 个月前不在该领域的人。非程序员正在与智能体结对并交付真实的软件。博士们被那些选择了正确原语并开始行动的构建者超越。大门是敞开的。大多数人仍在试图找到申请表。你实际上需要培养的技能不是“智能体”。而是确定哪些工作能在一个表面不断变化的领域产生复利的纪律。上下文工程复利。工具设计复利。编排器-子智能体模式复利。评估纪律复利。控制架思维模式复利。了解周二发布的框架的 API 并不。一旦你能把它们区分开来，每周发布的潮水就不再感觉像压力，而开始感觉像你可以忽略的噪音。你不需要学所有东西。你需要学习能复利的东西，跳过不能复利的东西。选择一个结果。在发布前连接追踪和评估。使用 LangGraph 或你团队的同类产品。使用 MCP。沙箱化你的运行时。默认单智能体。当失败模式将其拉入时才增加范围。每季度重新评估模型。周五读三样东西。这就是行动手册。剩下的就是品味、交付速度，以及不追逐不重要事情的耐心。构建东西。把它们放到互联网上。这个时代奖励做东西的人，胜过能描述东西的人。做一个做东西的人从未有过比现在更好的窗口。

🔗 相关文档