Huang Yihe's evolving judgments and practical work on the concept of Agent spanning from 2024-04 to 2026-05. The full cognitive sedimentation from the earliest view that "the difficulty of Multi-Agent lies in Workflow design" to building his own multi-agent orchestration product newtype OS in 2026.
When to open:
- You are designing an Agent system but cannot distinguish between Workflow / Agent / Agentic Workflow
- When you hear about "general-purpose Agent" / "Manus-like products", you don't know whether they are worth following
- You feel Claude Code Sub-agents are "somehow not enough" and want to know what real multi-agent orchestration looks like
- You want to build an Agent product but don't know how to improve delivery rate
0. Concept Map
graph TD
A["Workflow<br/>空间结构 · 静态<br/>'做什么 / 按啥顺序'"] --> C["Agentic Workflow<br/>骨架 Workflow + 关键节点 Agent"]
B["Agent<br/>逻辑结构 · 动态<br/>'此时此刻该怎么办'"] --> C
C --> D["Multi-Agent 编排<br/>多个 Agent 协作<br/>(Chief / Deputy / 各角色 Sub-agent)"]
D --> E["Agent Native 协议<br/>专为 Agent 设计的 HTTP<br/>(预测 2026 后半年)"]
Core distinction (Post 1761, 2025-09):
| Workflow | Agent | |
|---|---|---|
| Essence | Define tasks and the dependency relationships between tasks | Perceive the environment + make autonomous decisions + execute actions |
| Form | Flowchart / blueprint (static) | A sequence of actions unfolding over time (dynamic) |
| Core | Dependency relationships | Decision-making and execution |
| Focus | "What to do / in what order" | "What to do right now" |
| Abstraction level | High (business process) | Low (execution intelligence) |
The two are not substitutes; they complement each other:
- A piece of work = Spatial structure (Workflow) + logical structure (Agent)
- A complex Workflow may be completed through collaboration among multiple Agents
- Treating Agents as Workflow nodes → Agentic Workflow
1. The core fatal weakness of Multi-Agent: Workflow design (Post 69, 2024-04)
Lao Huang's earliest judgment(stated in the second month after starting newtype):
"Technically, building a Multi-Agent System is not hard at all. The hard part is that you have to think clearly about how you want the Agents to act."
Analogy: An Agent is like an intern who writes well. If you hire him, throw a pile of materials at him and say "finish an article in 10 minutes", he will definitely be lost. So you must decompose tasks from a system perspective → turn them into a set of Workflows → map them onto Agents.
Core conclusion: The value of Agent lies in Workflow. And how to design Workflow requires you to understand both AI and business.
Why this is the root cause of failure for 90% of industry projects:
- Most teams get stuck on "training models / tuning Prompts" and do not put effort into Workflow design
- Without Workflow, an Agent is just a chatty toy that cannot produce sustained output
- Business understanding is the real moat for Multi-Agent; Prompt engineering is superficial
When to apply:
- Before starting an Agent project, first draw a Workflow flowchart and write down every step clearly in plain language
- When stuck on "poor Agent performance", ask yourself "Is my Workflow decomposed finely enough? Which node is the most ambiguous?"
2. Agentic Workflow: Evolution path (Post 1761, 2025-09)
Evolution order:
- Initially: Simple / fixed tasks are fully automated with Workflow (pure flowchart)
- When encountering complex tasks: Some nodes in the process contain a great deal of uncertainty and require natural language understanding / dynamic interaction with the external environment
- Introduce Agents to fill in complex nodes → this is Agentic Workflow
Figurative metaphor:
Workflow: [步骤1] → [步骤2] → [步骤3] → [步骤4] → 结果
↓
这一步太模糊
↓
Agentic Workflow: [步骤1] → [步骤2] → [Agent 自主决策] → [步骤4] → 结果
Why this is the correct approach for Agent landing:
- Full Workflow is too rigid and cannot handle complex scenarios
- Full Agent is uncontrollable and has low delivery rate (see §5)
- Agentic Workflow = The vast majority of nodes are deterministic, with key nodes left to Agent autonomy = balances controllability + flexibility
When to apply: When designing Agent products, start from pure Workflow by default, insert Agents only at nodes that truly require "understanding + decision-making", and do not jump straight to a "general-purpose Agent".
3. Agent Native protocol: Prediction after MCP (Post 1061, 2025-04)
Lao Huang's prediction in 2025-04:
Current Agent products (Computer Use / Browser Use) all make models adapt to human production environments. Because computers and browsers are built for humans. It is not impossible for AI to use them, but efficiency will definitely be low, and cost will definitely be high(Token expenditure, processing time). No team, no matter how strong, can solve this.
So eventually a set of Agent Native things will emerge, possibly a protocol (HTTP exclusive to Agents). Humans cannot read it and do not need to; it is designed specifically for Agents to obtain information and interact.
Predicted timeline: After MCP matures, possibly late 2025 or 2026.
Argumentation logic chain:
- MCP is a model-centric protocol that helps models evolve into Agents
- A large number of Agents emerge → only then will there be a necessity for an Agent Native protocol
- Everything now is a stopgap measure
Lao Huang's reflection in 2025-10 (Post 2535): newtype OS itself has gone fully CLI. It is not To Human, but To Agent. Command line + structured output = the interface form closest to Agent Native at present.
Why this judgment is decisive for product direction:
- Investing in Browser Use / Computer Use products = working to adapt Agents to Human-only interfaces = will be bypassed in the long run
- Investing in Agent Native interfaces (CLI / API / Protocol) = directly benefits when Agent Native protocols emerge
When to apply:
- When seeing products like "AI Operator / Computer Use Agent", ask "Is its interface Human-first or Agent-first? Is it an intermediate form?"
- When designing your own product interfaces, default to CLI / structured API, not GUI (unless users need it)
4. The logic of CLI Agent (Post 1461, 2025-07)
Why Claude / Gemini both launched CLI AI programming tools(Lao Huang's interpretation):
Command-line Agent = the vast existing tool ecosystem + classic Unix composition philosophy + modern AI scheduling capabilities (such as ReAct)
The future it points to:
Command-line Agent + mature MCP ecosystem = general-purpose Agent skeleton
Four-stage execution loop:
- Perceive: The Agent fully understands your intent and current system state through MCP
- Think: The LLM brain performs reasoning
- Act: The Agent executes a series of commands through the CLI interface
- Loop verification: The Agent checks the file system again through MCP, confirms task completion, and reports to the user
Why CLI is 10 times stronger than GUI (for Agents):
- Decades of composability of Unix tools (pipes, stdin/stdout) are Agent-friendly; GUI is not Agent-friendly
- CLI output is text/JSON, which Agents can directly digest; GUI output is pixels, requiring Agents to do OCR first
- CLI operations can be batched / concurrent / retried on failure; GUI requires click simulation, which is slow and fragile
When to apply:
- When evaluating AI tools, prioritize those with a CLI version (to prepare for future Agent-ification)
- When designing interfaces for your own tools,build CLI first; GUI is a nice-to-have
5. Improving Agent delivery rate: 3 rules (Post 2208, 2026-01)
Lao Huang's judgment framework for Agent products:
| Rule | Content | Essence |
|---|---|---|
| 1 | Clear tasks | Subtraction: boundaries must be tight |
| 2 | Closed scenarios | Subtraction: do not let Agents run wild in an infinitely open world |
| 3 | Verifiable results | Closed loop: there must be an automated way to verify whether Agent output is correct |
Core insight:
The trap of general-purpose Agents is trying to solve ambiguous problems in an infinitely open world. However, current AI capabilities are still probabilistic. To achieve deterministic product delivery, you must artificially limit the search space.
Emphasis on point 3:
If you want to build a successful Agent, first ask:What automated means do I have to verify that what the AI generates is correct? If you don't have any, your product will struggle to move past the Demo stage.
Why these 3 rules determine product life or death:
- Without rule 1 + rule 2 → the Agent goes off track, and users don't know what it is doing
- Without rule 3 → users have to manually verify every time, the cost of use is higher than not using it, and no one will use the product
- None of the three are needed for Demo, but all three are needed for production → this is why many Demo products die after launch
When to apply:
- Before starting an Agent project, answer these 3 questions first. If you can't answer them = the project is not ready to start
- When seeing a viral Agent Demo, ask "Does it satisfy these 3 rules in production?" (The answer for most is no)
6. Reasons why Manus is not favored (Post 941, March 2025)
Lao Huang's face-to-face diss in 2025-03(Market frenzy at the time of Manus's release):
If you have used Claude / Cursor / Deep Research frequently in the past six months, seeing this kind of requirement decomposition / information gathering / tool calling approach,you won't be shocked, you'll just smile slightly.
Manus's fatal weakness: General-purpose Agent is a battlefield that giants (OpenAI / Anthropic / Google) pay close attention to.
"Having something going for it" is not enough to survive being crushed by the three companies.All tinkering built on top of models will be covered by model capability upgrades. Without your own model, you can only be a flash in the pan.
Lao Huang's prediction: Domestic media will keep hyping it (the "Chinese AI" narrative needs DeepSeek to represent models + Manus to represent Agents), and Manus will take the chance to raise more money and wait for variables.
Why this judgment matters:
- Any product competing in the "general-purpose Agent" / "general-purpose Coding Agent" track is racing against the next-generation models of model vendors
- Every time a model generation upgrades, the previous generation's "wrapper" on general-purpose Agents gets eaten by native capabilities (typical example: GPT-4 comes with Browser → replaced many Browser Use products)
When to apply:
- When hearing any narrative about "general-purpose Agent" / "using Agents to eliminate all SaaS", first ask "Will this product still exist after model v+1 comes out?"
- When choosing product directions,avoid directions that model companies will definitely build in the future(general Coding / general Browser / general Research)
7. Claude Code Sub-agents are not "real multi-agent orchestration" (Post 2266, 2026-01)
Lao Huang's analysis:
Claude Code's Sub-agents do not count as the "multi-agent orchestration" the industry expects; they are only a multi-agent mechanism.
5 major characteristics of real multi-agent orchestration:
| # | Characteristic | Content |
|---|---|---|
| 1 | Hierarchical and Nested Orchestration | Supports meta-orchestrators managing sub-orchestrators (teams of teams), allowing complex delegation chains + debate/review mechanisms |
| 2 | Multi-Model / Cross-Provider Support | Different Agents use different models (Opus for planning / Flash for execution / Grok for search), optimizing cost/performance |
| 3 | Shared State and Advanced Coordination | Persistent memory / conflict resolution / dynamic routing / loop iteration / error recovery, managed by external code or frameworks |
| 4 | True Parallelism and Scalability | Supports tens or even hundreds of concurrent Agents, suitable for long-running / large-scale tasks (full-stack application refactoring / enterprise automation) |
| 5 | Open Source / Programmable Flexibility | Developers define workflows in code, rather than relying on a single LLM's "natural language delegation" |
The Actual Position of Claude Code Sub-agents:
"Internal task routing + lightweight delegation, not an independent multi-agent framework.Entry-level, only suitable for simple scenarios. "
When to Use:
- When evaluating Claude Code usage, recognize that Sub-agents are "lightweight delegation" rather than "full orchestration"
- When building serious multi-agent products, use these 5 points as a product requirements checklist
- When selecting a Multi-Agent framework, if it fails to meet 3 or more of the 5 criteria, it is just a toy
8. Multi-Agent Orchestration in Practice with newtype Profile (Post 2276, 2026-01)
Architecture:
Chief(主 Agent / 编排者)
↓ 拆解 + 分派
Deputy(副手 / 执行官)
↓ 再分派
Researcher / Editor / Fact-checker / ... (各特定角色 Agent)
Key Behaviors:
- Clear division of labor: The Chief only orchestrates and converses, and does not do the work itself
- Parallel execution: Multiple Researcher tasks run simultaneously
- Transparent and controllable: The task list in the upper right corner shows background progress in real time
- Human-machine collaboration: While background tasks are running, the Chief discusses details with the user and confirms requirements
- Structured output: Final results are aggregated into readable formats such as tables and lists
Agent Model Configuration (Lao Huang's Practical Setup):
| Agent | Which model to use | Reason |
|---|---|---|
| Chief | Claude(Opus 4.6) | Strong planning + logical reasoning capabilities |
| Deputy | Claude | Same as above |
| Researcher | Gemini | Large context window |
| Other execution-type models | Gemini Flash / Claude Sonnet | Depends on cost/speed requirements |
Why This Architecture Validates the 5 Key Characteristics in §7:
- Hierarchical (Chief → Deputy → Role Agents) ✓
- Multi-model (Claude + Gemini hybrid) ✓
- Parallel execution ✓
- Persistent memory (via newtype-profile.json +.config folder) ✓
- Code-defined (SKILL.md + profile JSON, not natural language commands) ✓
When to Use:
- When designing your own Multi-Agent product, directly copy this three-layer Chief / Deputy / Specialist architecture
- When explaining "what true multi-agent orchestration means", show this diagram to the other person
9. AI Agent = New Content (Post 2274, 2026-01)
Lao Huang's Judgment:
Old content is just a snapshot of information.New content is an entity that encapsulates knowledge / logic / tools. It is alive.
User operations on it are "asking questions" / "invoking" / "collaborating".
Agents redefine the "delivery form" and "consumption method" of information. It makes content no longer merely a carrier of information,but a carrier of services.
Implications for Content Creators:
For Content Creators, this is a table-flipping level opportunity.
Logical Deduction:
- Creating content in the past = writing articles / shooting videos → it ends when the user finishes watching
- Creating content now = encapsulating it into Agents / Skills / plugins → users directly invoke it whenever they need, generating continuous value
- Content creators' moat expands from "content quality" to "the ability to convert content → services"
Example: Lao Huang fed hundreds of his own video scripts to Gemini, extracted the "Three Tables of Personal Operating System" (concept table / relationship table / process table) → then these abstracted elements became Skills / Profiles → when AI calls newtype-os, it is invoking Lao Huang's content accumulated over the past 3 years.
When to Use:
- If you are a Content Creator and want to "go beyond pure content", ask "Can my content be encapsulated into an invocable Agent?"
- If you are building a SaaS product and want to add a content moat, ask "Can the SOP / Knowledge in my product be opened up as Skills for users' Agents to invoke?"
10. Three Layers of the Agent Personal Production System (Post 2462, 2026-02)
Architecture:
┌─────────────────────────────────────┐
│ 1. 知识库层(Knowledge Layer) │
│ - 外部资料(历史数据 / 行业报告) │
│ - 个人资料(过往笔记 / 视频脚本) │
├─────────────────────────────────────┤
│ 2. 技能层(Skill Layer) │
│ - Skills 封装的经验 SOP │
│ - Sub-agents 配置 │
│ - 多 Agent 编排(newtype Profile)│
├─────────────────────────────────────┤
│ 3. 实时信息层(Realtime Layer) │
│ - 新闻 / 新视频 / 长文章 │
│ - 通过 OpenClaw / Kimi Claw 定时 │
└─────────────────────────────────────┘
Lao Huang's Own Progress (Self-assessment, 2026-02):
- Knowledge base layer: Completed (built and shared across multiple videos in 2024)
- Skill layer: In progress (multiple Skills released in 2025, multi-agent orchestration to be completed in 2026)
- Real-time information layer: Previously had no good solution; automated using OpenClaw / Kimi Claw during 2026 Spring Festival
Why Three Layers Instead of One:
- Knowledge ≠ Skills ≠ Real-time data, they have different lifecycles, different refresh frequencies, and different management methods
- Mixing them together will cause the AI system to lose control (old knowledge mixed with new events, Skill trigger conditions become chaotic)
- Three independent layers → can be upgraded independently and debugged independently
When to Use:
- When building your own AI system, first divide folders according to these 3 layers, and design SOPs independently per layer
- When evaluating others' AI systems, ask "Are all 3 layers present? Which layer is the weakest?"
11. Three-Layer Framework for the AI Era (Post 2360, 2026-02)
Lao Huang's navigation map for the entire AI industry:
First Layer: Technology Stack (from bottom to top)
- Bottom layer: Model capabilities (Pre-training → Reasoning → Long Horizon)
- Middle layer: Infrastructure (Framework → Harness → Memory System)
- Upper layer: Application scenarios (Coding → SRE → Research → Vertical)
Second Layer: Value Chain (from supply to demand)
- Supply side: AI creates new capabilities (e.g., Long Horizon Agent)
- Transmission layer: New capabilities restructure Workflows (e.g., GitHub evolves from a code repository to a task dispatch system)
- Demand side: New workflows create new demand (e.g., "writing code with AI" becomes the norm)
Third Layer: Competitive Landscape (from general to specialized)
- General layer: Model vendors (OpenAI / Anthropic) compete for the entry point
- Infrastructure layer: Independent players (LangChain / MemOS) provide portable capabilities
- Application layer: Vertical companies (Factory / Rogo) build barriers in specific scenarios
Strategic Implications for Different Roles
Entrepreneurs:
| Which layer to target | Strategy |
|---|---|
| Bottom layer (models/engines/memory systems) | Pursue generality, build technical barriers, aim to become infrastructure |
| Middle layer (Harness/toolkits) | Pursue best practices, iterate quickly, aim to become the de facto standard |
| Upper layer (vertical applications) | Pursue scenario fit, accumulate memory assets, aim to build domain moats |
Investors:
| Which layer to look at | What to focus on |
|---|---|
| Bottom layer | Technical barriers, whether there is a possibility of "enveloping" other technologies |
| Middle layer | Engineering capability, whether model capabilities can be converted into usable products |
| Upper layer | Scenario depth, whether irreplicable memory assets can be built in vertical domains |
Individuals:
| Dimension | Shift |
|---|---|
| Cognition | Shift from the "demand side" to the "supply side", from "what do I need" to "what can I create" |
| Capability | Coding may become the new "literacy"; you don't have to become a programmer, but you need to understand code logic |
| Assets | Your collaborative memory with AI is your personal asset; you should consciously manage and accumulate it |
When to Use:
- When evaluating any AI product/project, first locate which layer it is in → estimate its ceiling and competitors
- When making your own decisions, ask "Which side of the second layer (value chain) am I on? Demand side or supply side?"
12. Page Rank → Agent Rank (Post 1317, 2025-05)
Prediction: After search engines evolve into question-answering engines,the traffic distribution rules of the entire ecosystem will be rewritten.
Impact on tool websites:
| Past | Future |
|---|---|
| Tool websites for looking up IP addresses / converting JPG to PNG, etc., relied on Google referrals + ad monetization | User click behavior decreases → the Page Rank dividend for tool websites disappears |
| Users enter keywords and select the highest-ranked result | AI gives answers directly, and tool invocation becomes an internal behavior of Agents |
Core Opportunity:
Some tool capabilities will be internalized by models, but there are still many that are not worth internalizing and can be satisfied by invoking a small/micro Agent. This could be a unassuming big opportunity.
Why This Judgment Is Valuable:
- You don't need to build a "disruptive AI application"; building "small tools frequently invoked by Agents" is also a huge opportunity
- The standard for evaluating your own product shifts from "how many users you have" to "how frequently it is invoked by Agents"
- Once a product is habitually invoked by Anthropic / OpenAI's Agents, it gains a moat
When to Use:
- When building small tool products, design interfaces that are "easy for Agents to invoke" (REST / MCP server) instead of only having a Web UI
- When evaluating old tool websites, ask "Will GPT-5 internalize its capability? If so, how can it save itself?"
13. General Agents Should Focus on "Making Things Easier" Rather Than "Making People Stronger" (Post 1772, 2025-09)
Lao Huang's Product Direction Insight:
OpenAI's "How People Use ChatGPT" report validates a feeling I have: besides making people stronger, AI has another very easily overlooked but extremely rigid demand — making things easier for people.
Typical Scenarios:
- Many users with good cognition want AI to help write a rough draft first (for writing), or answer questions / gather information
- It's not that they can't do it, they want to take it easier, and take over after AI completes 70-80% of the foundation
ChatGPT / the Big Three can satisfy more than half of the needs, and the remaining large number of niche / vertical needs → will be filled by individual small AI products.
Lao Huang's Product Direction Formula:
A single-point breakthrough insight + Claude Code SDK as the Agent engine + a modern, aesthetic UI = may have higher odds of success than those projects trying to build an OS / platform
Why This Is Counterintuitive:
- The industry focuses on "how cool things AI Agents can do" (making people stronger)
- Real user demand is "can AI let me do less work" (making things easier)
- The niche market on the "ease" dimension is severely underestimated
When to Use:
- When you want to build an AI product but don't know what to build, start from "things users can already do but find annoying", rather than "things users can't do"
- When you see the narrative "our AI improves efficiency by N times", ask in return "Do users want to be faster, or do they want it to be easier?"
14. Context > Compute (Post 2248, 2026-01)
Core Mindset:
Context > Compute
Be an architect of the middle layer.
Whoever has the most precise Prompts and the most complete Context has the highest "intelligence conversion rate".
Meaning:
- Model capability (Compute) is growing rapidly, but the actual output quality users get depends not only on the model, but more on the quality of the Context fed into it
- Feeding GPT-3 carefully prepared Context may produce better results than feeding GPT-5 a vague Prompt
- Middle-layer architect = someone who designs Context pipelines = a role more valuable than "tuning models"
Why This Affects Personal Skill Investment Direction:
- Learning "prompt engineering" → already largely replaced by Prompt Houses / tools
- Learning "Context Engineering" (how to assemble, clean, compress, and retrieve Context for models) → long-term value appreciation
- Learning "building infrastructure" (knowledge bases / Memory Systems / Retrieval) → the middle layer will always be needed
When to Use:
- When choosing a learning plan, pick Context Engineering-related content rather than pure Prompt engineering
- When evaluating products, focus on their Context management capabilities (retrieval quality / memory strategy), not just model selection
15. The Correct Response When an Agent Makes a Mistake (2026-03 Post 2579)
Mindset:
When an Agent makes a mistake, your first reaction should not be "try again", but instead think about:What capability is missing from the environment.
Meaning:
- When an Agent is wrong → it is not that the model is stupid, but that there are gaps in its toolbox / Context / verification mechanisms
- "Try again" is stochastic gambling and cannot fix the root cause
- Identify what is missing → add Skill / MCP / Memory → it will naturally be correct next time
Why this is the correct posture for debugging Agent products:
- Most people's instinct is to "change the Prompt and rerun", which is a surface fix
- The real fix is at the architecture level: add new tools / add new data sources / add new verification steps
- This is just like how programmers debug: once an error can be reproduced, the root cause can definitely be located, rather than "gambling that it will pass next run"
When to use:
- When an Agent is wrong, stop first. Ask "What does it need that I did not provide" (tools? data? verification?)
- When evaluating Agent products, see whether their handling after errors is retry or capability supplementation
16. Anti-patterns: Avoid These Pitfalls in Agent Design
| ❌ | ✅ |
|---|---|
| Building a "general-purpose Agent" right off the bat | Start with a single-point Agentic Workflow and verify the three rules in §5 |
| All Workflow or all Agent | Agentic Workflow: Workflow as the skeleton + Agents at key nodes |
| Choosing the most expensive model | Use different models for different Agents; the Researcher uses a large-context model, and the Chief uses a strong reasoning model |
| Retrying whenever an Agent makes a mistake | Think about "what capability is missing from the environment" and supplement Skill / MCP / Memory |
| Competing with giants in the general-purpose track | Avoid directions that model companies will definitely build in the future (Manus's fatal weakness) |
| Designing Agent interfaces with only GUI | Default to CLI; GUI is a nice-to-have |
| Treating Claude Code Sub-agents as a multi-Agent framework | It is "lightweight delegation"; for serious multi-Agent scenarios use OpenCode / LangGraph / build your own |
| Dumping all content to the Agent | Separate into three layers (knowledge base / skills / real-time information) and manage them independently |
| Emphasizing that "AI makes users stronger" | Pay equal attention to "AI makes users' lives easier" (an underrated dimension) |
| Competing on Prompt Engineering | Learn Context Engineering (mid-layer architect) |
References and Extensions
Main references: Featured posts from newtype Knowledge Planet: 69, 941, 1061, 1317, 1461, 1761, 1772, 1812, 1902, 1912, 2208, 2248, 2266, 2274, 2276, 2360, 2462, 2535, 2579
Companion wiki:
- newtype Mindset · Super Individual Methodology — Personal values / mindset foundation
- newtype · Vibe Coding Independent Product in Practice — Product evolution from Lao Huang's real practice (newtype Profile / CLI / OS)
- (TODO)newtype · MCP Protocol and Ecosystem in Practice — Deep dive into the MCP protocol
- (TODO)newtype · RAG in Practice and Knowledge Base Evolution — RAG + knowledge base (Layer 1 of the three-layer architecture)
- (TODO)newtype · Prompt / Context Engineering in Practice — Advanced Prompt usage + Context Engineering
Cross-series related:
- Wang Kai SOP
multi-agent-browser-matrix-v1.1.md(Phase 2 processing) — Multi-Agent browser matrix architecture, a parallel implementation to §8 of this wiki - Wang Kai
Claude-Code 工作流方法论综述.md(Phase 2) — Internal use of Claude Code Sub-agents, strongly related to the analysis in §7 of this wiki
History
- 2026-05-16 v1.0 created — Extracted wiki #3 from the full newtype post index (Phase 1.1 · 3/12). Core coverage: Agent / Multi-Agent / Workflow / Agentic Workflow / Agent Native / CLI Agent / 3 rules for improving delivery rate / Manus's fatal weakness / limitations of Claude Code Sub-agents / newtype Profile architecture / Agent = New Content / three-layer framework. Source session: Session 2 wiki slices.