@moon791017/neo-skills 1.1.21 → 1.1.23
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +47 -67
- package/README.md +2 -30
- package/package.json +1 -1
- package/skills/neo-clarification/assets/clarification-template.md +4 -4
- package/skills/neo-harness/SKILL.md +75 -0
- package/skills/neo-harness/assets/AGENTS.md.template +63 -0
- package/skills/neo-harness/references/execution-protocol.md +47 -0
- package/skills/neo-harness/references/harness-assessment.md +67 -0
- package/skills/neo-harness/references/orchestration-patterns.md +46 -0
- package/skills/neo-harness/scripts/generate-agents-md.py +266 -0
- package/skills/neo-agent-harness/SKILL.md +0 -127
- package/skills/neo-agent-harness/reference/agent-harness-engineering.md +0 -343
- package/skills/neo-agent-harness/reference/harness-patterns.md +0 -194
- package/skills/neo-agent-harness/reference/loop-engineering.md +0 -149
- package/skills/neo-agent-protocol/SKILL.md +0 -68
- package/skills/neo-agent-protocol/reference/agent-execution-rules.md +0 -58
- package/skills/neo-agentic-design/SKILL.md +0 -89
- package/skills/neo-agentic-design/evals/eval_queries.json +0 -58
- package/skills/neo-agentic-design/evals/evals.json +0 -27
- package/skills/neo-agentic-design/references/advanced-safety.md +0 -158
- package/skills/neo-agentic-design/references/base-workflows.md +0 -219
- package/skills/neo-agentic-design/references/resilience-hitl.md +0 -105
- package/skills/neo-agentic-design/references/system-components.md +0 -93
|
@@ -1,219 +0,0 @@
|
|
|
1
|
-
# Base Patterns & Workflows
|
|
2
|
-
|
|
3
|
-
This document provides conceptual designs for basic agentic orchestration patterns, covering prompt chaining, routing, parallelization, reflection, tool use, planning, and multi-agent collaboration.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## Chapter 1: Prompt Chaining
|
|
8
|
-
|
|
9
|
-
### 1. Definition
|
|
10
|
-
Decomposes a complex task into multiple **sequentially dependent subtasks**. The structured output of the previous step serves as the input for the next step. Each step focuses on a single, clear objective.
|
|
11
|
-
|
|
12
|
-
### 2. Problems Addressed
|
|
13
|
-
* Context dilution: Prevents the LLM from losing focus when processing large, complex tasks.
|
|
14
|
-
* Instruction drift: Avoids failures in a single prompt that contains too many rules.
|
|
15
|
-
|
|
16
|
-
### 3. Workflow
|
|
17
|
-
```mermaid
|
|
18
|
-
graph LR
|
|
19
|
-
Input[Raw Input] --> Step1[LLM Step A]
|
|
20
|
-
Step1 -->|Structured Output A| Step2[LLM Step B]
|
|
21
|
-
Step2 -->|Structured Output B| Step3[LLM Step C]
|
|
22
|
-
Step3 --> Output[Final Answer]
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
### 4. Trade-offs
|
|
26
|
-
* **Pros**: High predictability; easy to optimize prompts and perform unit testing for individual steps.
|
|
27
|
-
* **Cons**: High total latency due to sequential execution; errors in earlier steps propagate downstream (Error Cascade).
|
|
28
|
-
|
|
29
|
-
### 5. Use Cases
|
|
30
|
-
* Multi-step article generation (Outline -> Draft -> Polish -> Format).
|
|
31
|
-
* Data extraction and compliance analysis.
|
|
32
|
-
|
|
33
|
-
---
|
|
34
|
-
|
|
35
|
-
## Chapter 2: Routing
|
|
36
|
-
|
|
37
|
-
### 1. Definition
|
|
38
|
-
Dynamically redirects tasks to the most suitable execution path, specialized tool, or sub-agent based on input characteristics. Routing decisions are made by rule engines, semantic similarity, or LLM classifiers.
|
|
39
|
-
|
|
40
|
-
### 2. Problems Addressed
|
|
41
|
-
* Resource waste: Avoids using expensive, slow high-tier models for simple queries.
|
|
42
|
-
* Tool clutter: Avoids crowding too many unrelated tools into a single agent's context window.
|
|
43
|
-
|
|
44
|
-
### 3. Workflow
|
|
45
|
-
```mermaid
|
|
46
|
-
graph TD
|
|
47
|
-
Input[User Input] --> Router[Routing Classifier / LLM]
|
|
48
|
-
Router -->|Path A| AgentA[Specialized Agent A / Tool A]
|
|
49
|
-
Router -->|Path B| AgentB[Specialized Agent B / Tool B]
|
|
50
|
-
Router -->|Path C| AgentC[Specialized Agent C / Tool C]
|
|
51
|
-
```
|
|
52
|
-
|
|
53
|
-
### 4. Trade-offs
|
|
54
|
-
* **Pros**: High modularity; reduces average system latency and token consumption.
|
|
55
|
-
* **Cons**: Routing errors directly cause downstream task failures; an extra routing decision layer adds minor latency.
|
|
56
|
-
|
|
57
|
-
### 5. Use Cases
|
|
58
|
-
* Customer support dispatching (e.g., routing to billing, tech support, or returns agents).
|
|
59
|
-
* Pre-filtering for tool calls.
|
|
60
|
-
|
|
61
|
-
---
|
|
62
|
-
|
|
63
|
-
## Chapter 3: Parallelization
|
|
64
|
-
|
|
65
|
-
### 1. Definition
|
|
66
|
-
Splits a large task into multiple **independent subtasks** executed in parallel (Fork) and aggregates the results at a single point (Join).
|
|
67
|
-
|
|
68
|
-
### 2. Problems Addressed
|
|
69
|
-
* Cumulative linear latency: Solves the high time cost associated with sequential multi-step execution.
|
|
70
|
-
* Single-perspective limitation: Collects diverse solutions to the same problem simultaneously for synthesis.
|
|
71
|
-
|
|
72
|
-
### 3. Workflow
|
|
73
|
-
```mermaid
|
|
74
|
-
graph TD
|
|
75
|
-
Input[Raw Query] --> Splitter[Splitter]
|
|
76
|
-
Splitter --> TaskA[Parallel Task A]
|
|
77
|
-
Splitter --> TaskB[Parallel Task B]
|
|
78
|
-
Splitter --> TaskC[Parallel Task C]
|
|
79
|
-
TaskA --> Syn[Synthesis / Aggregator]
|
|
80
|
-
TaskB --> Syn
|
|
81
|
-
TaskC --> Syn
|
|
82
|
-
Syn --> Output[Aggregated Output]
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
### 4. Trade-offs
|
|
86
|
-
* **Pros**: Significantly reduces elapsed time; suitable for large-scale parallel filtering.
|
|
87
|
-
* **Cons**: High spikes in token usage, easily triggering API rate limits; reconciling inconsistent results requires additional algorithms or LLM overhead.
|
|
88
|
-
|
|
89
|
-
### 5. Use Cases
|
|
90
|
-
* Static code analysis (checking security, performance, and style simultaneously).
|
|
91
|
-
* Large-scale information retrieval and cross-document comparison.
|
|
92
|
-
|
|
93
|
-
---
|
|
94
|
-
|
|
95
|
-
## Chapter 4: Reflection (Self-Correction)
|
|
96
|
-
|
|
97
|
-
### 1. Definition
|
|
98
|
-
Introduces a dual-entity feedback mechanism: a Generator and a Critic. The Generator produces an initial draft, the Critic evaluates it for quality and provides feedback, and the Generator iteratively refines the output until termination conditions are met.
|
|
99
|
-
|
|
100
|
-
### 2. Problems Addressed
|
|
101
|
-
* Unstable output quality: Prevents logical gaps, factual errors, or formatting anomalies.
|
|
102
|
-
* Overconfidence: Breaks cognitive blind spots of a single-turn generation via an independent critique mechanism.
|
|
103
|
-
|
|
104
|
-
### 3. Workflow
|
|
105
|
-
```mermaid
|
|
106
|
-
graph TD
|
|
107
|
-
Input[Task Goal] --> Gen[Generator]
|
|
108
|
-
Gen --> Draft[Initial Draft]
|
|
109
|
-
Draft --> Critic[Critic / Evaluator]
|
|
110
|
-
Critic --> Decision{Is Acceptable?}
|
|
111
|
-
Decision -->|No| Feedback[Feedback/Suggestions]
|
|
112
|
-
Feedback -->|Guide Correction| Gen
|
|
113
|
-
Decision -->|Yes| Output[Final Accepted Output]
|
|
114
|
-
```
|
|
115
|
-
|
|
116
|
-
### 4. Trade-offs
|
|
117
|
-
* **Pros**: Highly stable output quality, significantly reducing logical and formatting errors.
|
|
118
|
-
* **Cons**: Higher token consumption; extended execution time; potential for infinite loops if termination conditions are poorly defined.
|
|
119
|
-
|
|
120
|
-
### 5. Use Cases
|
|
121
|
-
* Automated code generation and testing (write code -> run tests -> fix based on errors -> re-test).
|
|
122
|
-
* Strict compliance document drafting.
|
|
123
|
-
|
|
124
|
-
---
|
|
125
|
-
|
|
126
|
-
## Chapter 5: Tool Use / Function Calling
|
|
127
|
-
|
|
128
|
-
### 1. Definition
|
|
129
|
-
The LLM reads the description format (schema) of external tools, autonomously decides when to call a tool and generates the parameters. The agent executes the tool in a sandbox or external system, and feeds the results back to the LLM for interpretation.
|
|
130
|
-
|
|
131
|
-
### 2. Problems Addressed
|
|
132
|
-
* Information lag: Connects the model to real-time data.
|
|
133
|
-
* Lack of computation: Solves difficulties in mathematics and precise logical operations.
|
|
134
|
-
* Inability to affect external systems: Allows agents to send emails, write databases, or call APIs.
|
|
135
|
-
|
|
136
|
-
### 3. Workflow
|
|
137
|
-
```mermaid
|
|
138
|
-
sequenceDiagram
|
|
139
|
-
participant U as User
|
|
140
|
-
participant L as LLM (Core Reasoning)
|
|
141
|
-
participant A as Agent Execution Sandbox
|
|
142
|
-
participant T as External Tool / API
|
|
143
|
-
U->>L: Query
|
|
144
|
-
L->>L: Identify context, decide to use clock tool
|
|
145
|
-
L-->>A: Return tool name & structured parameters
|
|
146
|
-
A->>T: Call external API
|
|
147
|
-
T-->>A: Return real-time data
|
|
148
|
-
A-->>L: Send execution result back as context
|
|
149
|
-
L->>L: Synthesize and reason
|
|
150
|
-
L->>U: Respond to user
|
|
151
|
-
```
|
|
152
|
-
|
|
153
|
-
### 4. Trade-offs
|
|
154
|
-
* **Pros**: Greatly expands the action capabilities and data retrieval scope of the agent.
|
|
155
|
-
* **Cons**: Risk of parameter generation errors; security risks with external tools (requires strict sandboxing); vulnerability to external API instability.
|
|
156
|
-
|
|
157
|
-
### 5. Use Cases
|
|
158
|
-
* Real-time data queries (weather, stock market, ERP systems).
|
|
159
|
-
* Data entry and control (sending notifications, database updates).
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
## Chapter 6: Planning
|
|
164
|
-
|
|
165
|
-
### 1. Definition
|
|
166
|
-
Decomposes a high-level goal into an ordered set of dependent execution steps. The planner dynamically rewrites the remaining steps (replanning) based on environmental feedback and new information to ensure the goal is reached.
|
|
167
|
-
|
|
168
|
-
### 2. Problems Addressed
|
|
169
|
-
* Goal drift: Prevents the agent from losing sight of the ultimate goal during multi-step execution.
|
|
170
|
-
* Dynamic environment changes: Automatically searches for alternative solutions if a step fails.
|
|
171
|
-
|
|
172
|
-
### 3. Workflow
|
|
173
|
-
```mermaid
|
|
174
|
-
graph TD
|
|
175
|
-
Goal[Ultimate Goal] --> Planner[Planner: Task Decomposition]
|
|
176
|
-
Planner --> Plan[Generate Step List 1, 2, 3...]
|
|
177
|
-
Plan --> Executor[Executor: Call tools / sub-steps sequentially]
|
|
178
|
-
Executor --> EnvFeedback[Environmental Feedback]
|
|
179
|
-
EnvFeedback --> Checker{Encounter obstacles/failure?}
|
|
180
|
-
Checker -->|Yes| Replanner[Dynamic Replanner: Update plan]
|
|
181
|
-
Replanner --> Plan
|
|
182
|
-
Checker -->|No| Next{All steps completed?}
|
|
183
|
-
Next -->|No| Executor
|
|
184
|
-
Next -->|Yes| Output[Goal Accomplished]
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
### 4. Trade-offs
|
|
188
|
-
* **Pros**: Highly adaptable; capable of autonomously handling complex, unstructured tasks.
|
|
189
|
-
* **Cons**: Very high cost in LLM calls for planning and replanning; plan errors propagate, drifting downstream actions away from the target.
|
|
190
|
-
|
|
191
|
-
### 5. Use Cases
|
|
192
|
-
* Autonomous research assistants (Deep Research: dynamically selecting keywords, assessing information quality, diving deep into unknown domains).
|
|
193
|
-
* Automated software development (architecture design -> module division -> sequential development).
|
|
194
|
-
|
|
195
|
-
---
|
|
196
|
-
|
|
197
|
-
## Chapter 7: Multi-Agent Collaboration
|
|
198
|
-
|
|
199
|
-
### 1. Definition
|
|
200
|
-
Distributes a large task among multiple **specialized agents with distinct personas and skills**. These agents coordinate task handoffs, discussions, and integration through a predefined collaboration topology.
|
|
201
|
-
|
|
202
|
-
### 2. Problems Addressed
|
|
203
|
-
* Cognitive limits of a single core: Avoids overloading a single system prompt with too many instructions and roles.
|
|
204
|
-
* Unclear division of labor: Emulates human teams by dedicating specialists to specific tasks.
|
|
205
|
-
|
|
206
|
-
### 3. Workflow
|
|
207
|
-
Four main collaboration topologies:
|
|
208
|
-
* **Handoffs (Network)**: Agent A finishes its task and hands over the context and control to Agent B.
|
|
209
|
-
* **Supervisor**: A central Supervisor agent coordinates, assigns tasks to specialists, and aggregates results.
|
|
210
|
-
* **Hierarchy**: Supervisors oversee sub-supervisors, delegating and aggregating tasks hierarchically.
|
|
211
|
-
* **Blackboard**: Agents read and write to a shared state space (blackboard), intervening autonomously as the state changes.
|
|
212
|
-
|
|
213
|
-
### 4. Trade-offs
|
|
214
|
-
* **Pros**: Modular and scalable; allows mixing different model sizes/strengths to optimize costs.
|
|
215
|
-
* **Cons**: High communication overhead (multi-turn dialogues between agents); complex state management; risk of infinite discussion loops or unclear ownership.
|
|
216
|
-
|
|
217
|
-
### 5. Use Cases
|
|
218
|
-
* Simulated software development teams (Product Manager -> Architect -> Engineer -> QA).
|
|
219
|
-
* Creative content generation and peer review.
|
|
@@ -1,105 +0,0 @@
|
|
|
1
|
-
# Resilience, Exceptions & HITL
|
|
2
|
-
|
|
3
|
-
This document provides conceptual designs for system resilience, human interaction, and knowledge grounding, covering exception handling, Human-in-the-Loop (HITL) gates, and Retrieval-Augmented Generation (RAG).
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## Chapter 12: Exception Handling and Recovery
|
|
8
|
-
|
|
9
|
-
### 1. Definition
|
|
10
|
-
Designs automatic detection, retry, fallback, and state rollback mechanisms for exceptions that may occur during agent execution (such as API timeouts, network disconnections, LLM format errors, and invalid tool parameters).
|
|
11
|
-
|
|
12
|
-
### 2. Problems Addressed
|
|
13
|
-
* System fragility: Prevents long-cycle workflows from breaking due to transient network or API issues.
|
|
14
|
-
* Format pollution: Guides the LLM to self-heal when its output does not conform to the expected JSON schema.
|
|
15
|
-
|
|
16
|
-
### 3. Workflow
|
|
17
|
-
```mermaid
|
|
18
|
-
graph TD
|
|
19
|
-
Step[Execute Tool / Call LLM] --> Success{Successful?}
|
|
20
|
-
Success -->|Yes| Next[Proceed to Next Step]
|
|
21
|
-
Success -->|No: Exception| Detector[Exception Detector]
|
|
22
|
-
Detector --> RuleCheck{Evaluate Exception Type}
|
|
23
|
-
RuleCheck -->|Network/Timeout| Retry[Auto Retry with Backoff]
|
|
24
|
-
RuleCheck -->|Format Error| Refine[Guide LLM to Self-Correct]
|
|
25
|
-
RuleCheck -->|Tool Failure| Fallback[Route to Fallback/Alternative Tool]
|
|
26
|
-
RuleCheck -->|Critical Error| Rollback[Rollback State to Checkpoint]
|
|
27
|
-
Retry --> Step
|
|
28
|
-
Refine --> Step
|
|
29
|
-
Fallback --> Step
|
|
30
|
-
Rollback --> UserEscalation[Human Intervention]
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
### 4. Trade-offs
|
|
34
|
-
* **Pros**: Improves system robustness and reduces manual maintenance costs.
|
|
35
|
-
* **Cons**: Excessive retries or fallbacks can mask underlying bugs or quietly degrade output quality.
|
|
36
|
-
|
|
37
|
-
---
|
|
38
|
-
|
|
39
|
-
## Chapter 13: Human-in-the-Loop (HITL)
|
|
40
|
-
|
|
41
|
-
### 1. Definition
|
|
42
|
-
Strategically embeds human review, intervention, and authorization mechanisms into the agent's autonomous decision-making workflow, combining human common sense, ethics, and legal judgment with AI automation.
|
|
43
|
-
|
|
44
|
-
### 2. Problems Addressed
|
|
45
|
-
* High-risk operations: Prevents agent errors when performing large financial transactions, deleting sensitive data, or executing legally sensitive actions.
|
|
46
|
-
* Automation boundaries: Requests human guidance when decision confidence falls below a set threshold.
|
|
47
|
-
|
|
48
|
-
### 3. Three Core Interaction Modes
|
|
49
|
-
````carousel
|
|
50
|
-
### 1. Human-in-the-Loop (HITL)
|
|
51
|
-
* **Mechanism**: The agent pauses when reaching a high-risk step (e.g., large bank transfer), suspends the task, and sends it to a pending review queue.
|
|
52
|
-
* **Workflow**: Agent pauses -> Human reviews (Approve/Reject/Modify) -> Agent receives input and resumes execution.
|
|
53
|
-
* **Key Characteristic**: Human approval is a mandatory gate.
|
|
54
|
-
<!-- slide -->
|
|
55
|
-
### 2. Human-on-the-Loop (HOTL)
|
|
56
|
-
* **Mechanism**: The agent executes tasks autonomously while a human supervisor monitors and adjusts strategies.
|
|
57
|
-
* **Workflow**: Human sets macro rules (e.g., transaction limits) -> Agent trades automatically -> Human monitors metrics -> Human intervenes via a Kill Switch if necessary.
|
|
58
|
-
* **Key Characteristic**: Human does not intervene in individual decisions but maintains macro-level oversight.
|
|
59
|
-
<!-- slide -->
|
|
60
|
-
### 3. Decision Augmentation
|
|
61
|
-
* **Mechanism**: The agent acts as an analytical assistant, gathering data and presenting candidates. Decision-making and execution are performed entirely by a human.
|
|
62
|
-
* **Workflow**: Human asks query -> Agent collects and analyzes data -> Agent proposes options A, B, and C with pros/cons -> Human selects and executes.
|
|
63
|
-
* **Key Characteristic**: Agent provides cognitive augmentation without execution authority.
|
|
64
|
-
````
|
|
65
|
-
|
|
66
|
-
### 4. Trade-offs
|
|
67
|
-
* **Pros**: Provides a safety net and compliance guarantee for high-risk decisions; collects human feedback to optimize agent alignment.
|
|
68
|
-
* **Cons**: Human intervention limits system scalability and speed; designing human-in-the-loop review queues increases development costs.
|
|
69
|
-
|
|
70
|
-
---
|
|
71
|
-
|
|
72
|
-
## Chapter 14: Knowledge Retrieval / RAG
|
|
73
|
-
|
|
74
|
-
### 1. Definition
|
|
75
|
-
Retrieves relevant information from a knowledge base before the LLM generates a response, injecting the retrieved text chunks into the prompt context to guide the LLM toward producing factually grounded answers.
|
|
76
|
-
|
|
77
|
-
### 2. Advanced Agentic RAG Variants
|
|
78
|
-
```mermaid
|
|
79
|
-
graph TD
|
|
80
|
-
subgraph Traditional RAG
|
|
81
|
-
Query[User Query] --> VectorSearch[Vector Similarity Search]
|
|
82
|
-
VectorSearch --> Context[Concatenate Context Chunks]
|
|
83
|
-
Context --> LLMGen[LLM Generates Response]
|
|
84
|
-
end
|
|
85
|
-
subgraph Graph RAG
|
|
86
|
-
GQuery[User Query] --> GraphSearch[Navigate Knowledge Graph Nodes & Edges]
|
|
87
|
-
GraphSearch --> UnifiedContext[Cross-document Context Linkage]
|
|
88
|
-
end
|
|
89
|
-
subgraph Agentic RAG
|
|
90
|
-
AQuery[User Query] --> AgentLayer[Agent Decision Layer]
|
|
91
|
-
AgentLayer -->|1. Decompose Task| SubQueries[Multi-step Sub-retrieval Tasks]
|
|
92
|
-
AgentLayer -->|2. Self-Reflection| SourceVal[Source Timeliness & Quality Check]
|
|
93
|
-
AgentLayer -->|3. Resolve Conflicts| ConflictRecon[Active Conflict Reconciliation]
|
|
94
|
-
AgentLayer -->|4. Tool Call| WebSearch[Web Search for Knowledge Gaps]
|
|
95
|
-
end
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
### 3. Problems Addressed
|
|
99
|
-
* Outdated knowledge: Bypasses the temporal limits of static training data.
|
|
100
|
-
* Hallucination: Restricts the model within factual boundaries using verified document contexts.
|
|
101
|
-
* Fragmented information: Resolves vector search limitations that struggle to answer comprehensive questions spanning multiple documents.
|
|
102
|
-
|
|
103
|
-
### 4. Trade-offs
|
|
104
|
-
* **Pros**: Minimizes factual errors; supports precise citations; imports private knowledge without retraining models.
|
|
105
|
-
* **Cons**: Highly sensitive to the quality of text chunking and embeddings; multi-step reasoning in Agentic RAG increases response latency.
|
|
@@ -1,93 +0,0 @@
|
|
|
1
|
-
# System Components & Protocols
|
|
2
|
-
|
|
3
|
-
This document provides conceptual designs for system architecture components, resources, and protocols, covering memory management, learning and adaptation, Model Context Protocol (MCP), and goal setting and monitoring.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## Chapter 8: Memory Management
|
|
8
|
-
|
|
9
|
-
### 1. Definition
|
|
10
|
-
Provides agents with the ability to store and retrieve information across sessions and tasks through persistence mechanisms. The memory system is generally divided into short-term and long-term memory, managed by a unified Memory Service.
|
|
11
|
-
|
|
12
|
-
### 2. Memory Classification
|
|
13
|
-
| Memory Type | Medium | Function | Eviction & Retrieval Mechanism |
|
|
14
|
-
| :--- | :--- | :--- | :--- |
|
|
15
|
-
| **Short-term** | Current Context Window | Stores current conversation context and task execution trajectory | Sliding window, context pruning, and summarization |
|
|
16
|
-
| **Long-term Semantic** | Vector Database / Knowledge Base | Retains factual knowledge, concepts, and external rules | Vector semantic retrieval based on user input |
|
|
17
|
-
| **Long-term Episodic** | Structured Database / Log Store | Records past task execution experiences and outcomes | Used for few-shot learning or similar scenario matching |
|
|
18
|
-
| **Long-term Procedural**| Codebase / Tool Definitions / Prompt Templates | Records Standard Operating Procedures (SOPs) and toolbox definitions for specific tasks | Dynamically loaded based on task type |
|
|
19
|
-
|
|
20
|
-
### 3. Problems Addressed
|
|
21
|
-
* Amnesia (Context limits): Prevents long conversations from causing the LLM to lose critical history.
|
|
22
|
-
* Repeated errors: Ensures the agent learns from past executions to improve decision success rates.
|
|
23
|
-
|
|
24
|
-
---
|
|
25
|
-
|
|
26
|
-
## Chapter 9: Learning and Adaptation
|
|
27
|
-
|
|
28
|
-
### 1. Definition
|
|
29
|
-
Enables the agent to autonomously modify prompts or self-modify execution code in a code sandbox (SICA - Self-Improving Coding Agent) by collecting behavioral feedback and rewards from interactions with the environment, users, or other agents.
|
|
30
|
-
|
|
31
|
-
### 2. Problems Addressed
|
|
32
|
-
* Static configuration lag: Solves the issue of agents failing to adjust when environmental rules change.
|
|
33
|
-
* High development cost: Eliminates the manual process of fine-tuning prompts.
|
|
34
|
-
|
|
35
|
-
### 3. Workflow
|
|
36
|
-
```mermaid
|
|
37
|
-
graph TD
|
|
38
|
-
Interaction[Agent-Environment Interaction] --> Result[Execution Results & Metrics]
|
|
39
|
-
Result --> evaluator[Evaluator / Scoring System]
|
|
40
|
-
evaluator -->|Feedback/Score| Learner[Learning Engine]
|
|
41
|
-
Learner -->|Self-Optimize Prompts or Refactor Code| AgentUpgrade[Upgraded Agent]
|
|
42
|
-
AgentUpgrade -->|Next Task Turn| Interaction
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
### 4. Trade-offs
|
|
46
|
-
* **Pros**: High potential for long-term self-evolution; can discover high-quality logic not designed by humans in specific vertical disciplines (e.g., mathematical proofs, code generation).
|
|
47
|
-
* **Cons**: Unpredictable evolution paths, which may generate harmful mutations; self-modifying prompts can lead to privilege escalation or security vulnerabilities; extremely high overhead for training and testing iterations.
|
|
48
|
-
|
|
49
|
-
---
|
|
50
|
-
|
|
51
|
-
## Chapter 10: Model Context Protocol (MCP)
|
|
52
|
-
|
|
53
|
-
### 1. Definition
|
|
54
|
-
A standardized **Client-Server communication protocol** that establishes a plug-and-play integration standard between LLMs/Agents (Clients) and external data sources, development tools, and API services (Servers). MCP standardizes three core types of context exchange: **Resources**, **Prompts**, and **Tools**.
|
|
55
|
-
|
|
56
|
-
```mermaid
|
|
57
|
-
graph LR
|
|
58
|
-
subgraph Agentic Client
|
|
59
|
-
Agent[AI Agent / LLM]
|
|
60
|
-
end
|
|
61
|
-
subgraph MCP Server
|
|
62
|
-
Res[Resources: Files/Databases]
|
|
63
|
-
Pmt[Prompts: Templates]
|
|
64
|
-
Tls[Tools: APIs/Sandboxes]
|
|
65
|
-
end
|
|
66
|
-
Agent <-->|Standard JSON-RPC 2.0| MCP_Link[MCP Protocol Layer]
|
|
67
|
-
MCP_Link <--> Res
|
|
68
|
-
MCP_Link <--> Pmt
|
|
69
|
-
MCP_Link <--> Tls
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
### 2. Problems Addressed
|
|
73
|
-
* Tedious integration: Avoids repeatedly writing custom wrapper code when developing new agents or integrating new tools.
|
|
74
|
-
* Fragmented context acquisition: Provides external data and actions to the model in a unified interface format.
|
|
75
|
-
|
|
76
|
-
### 3. Trade-offs
|
|
77
|
-
* **Pros**: Reduces integration costs for multiple tools and data sources; decouples data sources from reasoning entities; supports dynamic discovery.
|
|
78
|
-
* **Cons**: Protocol serialization and JSON-RPC wrapping introduce minor performance overhead; requires tool providers to actively adopt the protocol.
|
|
79
|
-
|
|
80
|
-
---
|
|
81
|
-
|
|
82
|
-
## Chapter 11: Goal Setting and Monitoring
|
|
83
|
-
|
|
84
|
-
### 1. Definition
|
|
85
|
-
Sets structured and quantifiable goals (SMART principles) before agent initialization, and introduces an independent monitor during the execution phase to observe progress in real time (Progress Checkpoints), detect blocks, and trigger human-agent collaboration escalation when necessary.
|
|
86
|
-
|
|
87
|
-
### 2. Problems Addressed
|
|
88
|
-
* Blind execution: Prevents agents from entering infinite retry loops when encountering logical obstacles, wasting budget.
|
|
89
|
-
* Lack of observability: Solves the black-box execution problem, providing a clear progress path.
|
|
90
|
-
|
|
91
|
-
### 3. Use Cases
|
|
92
|
-
* Automated marketing campaign execution.
|
|
93
|
-
* Long-cycle autonomous codebase refactoring.
|