The-Evolution-of-AI-Agents

# The Evolution of AI Agents The evolution of AI agents from simple chat models to complex systems that can interact with tools, systems, and engineers. This document provides a step-by-step guide on how AI agents have developed over time, along with code examples for educational purposes. For more details, refer to The-Evolution-of-AI-Agents.ipynb. ## How AI Agents Evolved This note explains how people moved from chat models that only chat to agents that can connect to tools, systems, and can be engineered to work in real-world applications. **On Cloud Studio**: First, run the next cell with `!pip install` to install dependencies; directly call the provided **DeepSeek API Key**. The weather service still uses **Open-Meteo**, no weather key is required. If you make the notebook public, be sure to remove the key. **What you need to know**: You need to know how to run all cells or execute them in order, and if you need to build your own agent, you also need to know how to write functions. # Training Objectives 1. The goal is to establish an intuitive understanding of data interaction with agents, knowing how all architectures, such as Harness, Skill, MCP, and Function Call, interact with large models. 2. Regardless of what open-source framework is mentioned, such as the recent Hermes and previous Openclaw, they are all built based on the basic unit concepts discussed below. After reading this document, everyone should be able to build their own agent according to their needs and understand the essence of any concept that media may hype. **Large models have nothing but prompt and output** ## Timeline of Development 1. **Tuning Large Model API**: Programs send a paragraph to a cloud model and get a piece of text back. 2. **Function Call**: People were not satisfied with models only outputting text; they needed models to output structured information on which function to call and what parameters to use—programs would execute them. 3. **MCP**: A standardized Function Call—a standard protocol for how to connect functions (discover tools, pass parameters, and return results) to facilitate interconnection between different themes and tool services; the capability is still "calling tools," no new magic. 4. **Skill**: Essentially, a prompt template that chooses to call—writing a **reusable manual** (when to use, steps, constraints, output style) that is usually put into **system** or independent documentation, making model behavior **stable and reproducible**. 5. **Harness Engineer**: Prompts, tools, memory, evaluation, monitoring, security—**a complete set of engineering** to ensure stable launch. From the timeline, we see the progression from "talking" (API call) to "doing things" (Function Call), then to "standard connection" (MCP) and "experience accumulation" (Skill), and finally to "a deliverable system" (Harness Engineer). In terms of engineering, it progresses from Prompt Engineer to Context Engineer to Harness Engineer, essentially still working around prompts, which is why we say **large models have nothing but prompt and output**. Next, we will embody this in actual code. The process ultimately aims to achieve from demand to agent to autonomous delivery. Think of large models like fuel, put into a cylinder called Function Call—it starts interacting with the real world, doing work. Use Skill to compose multiple cylinders into an engine, which is a crucial part of a car. However, having just an engine is not enough; you need tires, steering, brakes, accelerator, steering wheel, etc., to build a car. These components are like Harness Engineer. Below, we will go through key steps with a few short pieces of code.