This Juejin Agent tutorial makes a direct judgment: LLMs can't perceive real failures, so they mechanically repeat invalid calls—this is the root cause of most Agent projects crashing in real business scenarios.
What this is
The tutorial proposes an architecture called "Error as Observation." All tool errors—403 anti-crawl blocks, network timeouts, parsing failures—are no longer silently swallowed by try/except blocks in the programmer's code. Instead, they're packaged as standard OpenAI role='tool' messages and written into the conversation history, fed back to the LLM.
It sounds technical, but it answers a plain question: when AI hits a snag while working, who calls the shots? The traditional approach has developers write fallback logic for the AI—when an error occurs, just return immediately. When AI faces an unfamiliar environment, this "developer-written fallback for AI" cuts off its autonomous judgment—it doesn't even know it just failed, so it can only mechanically repeat ineffective actions.
Specific tactics: strip all try/except from tool functions, let errors bubble up naturally; the orchestration layer converts exceptions into "standard tool messages" and writes them into history; the system prompt explicitly states "the network is unstable, analyze the failure cause yourself"; then pair it with a "dynamic circuit breaker"—if a tool throws a fatal error consecutively, remove it from the tool list on the next request.
Industry view
This thinking isn't new in engineering circles—Anthropic and Google's internal Agent frameworks have long used similar patterns. But placed at the moment of Agent explosion, the significance is amplified: we've noticed that many enterprise Agent projects demo impressively, then crash the moment they hit real business—the essence is that they didn't build the "error as information" layer.
However, there are opposing voices. A senior architect at a major firm questions: throwing errors back to the LLM verbatim will significantly increase Token consumption, and conversation history will be "polluted" by error information—in the long run, this might actually teach AI to "make excuses"—even when the tool is fine, the model tends to suspect it's broken. A more practical concern: most domestic companies don't have a reliable tool ecosystem at all—Agents call out to fragile crawlers and unauthenticated APIs, so no matter how clever the error handling, it's just "failing beautifully."
Impact on regular people
For enterprise IT: when evaluating Agent projects, put "error handling capability" into the acceptance checklist—don't just watch whether the demo runs, see whether it can decide its own next step when offline, blocked, or when interfaces change.
For working professionals: many "AI assistants" look smart now, but really reset or talk nonsense the moment they hit edge cases. Once you understand this mechanism, you'll know which products are real engineering and which are just packaged demos.
For the consumer market: manage expectations—in the next 1-2 years, the "AI Agent services" you buy will likely work in 80% of scenarios, but perform like an amnesiac in the remaining 20% of edge cases. This is the industry reality, not any single product slacking off.