Respuesta rápida: un agente de IA no es más que un modelo de lenguaje que puede llamar a tu propio código. Describes un conjunto de herramientas, el modelo decide cuándo invocar una, tu aplicación la ejecuta y devuelve el resultado, y el modelo continúa desde ahí — en un bucle hasta que la tarea está terminada. sgcWebSockets te ofrece dos formas de construir esto en Delphi o C++ Builder: function calling del proveedor (el modelo pide llamar a una de tus funciones a través del componente de OpenAI, Anthropic o Gemini) y MCP (el Model Context Protocol abierto, donde tu servidor expone herramientas que cualquier cliente o agente compatible con MCP puede descubrir y llamar). Ambos usan la misma idea; eliges la que encaja con el lugar donde vive el agente.
A veces la gente imagina un "agente" como un modelo especial. No lo es. Es un modelo de chat corriente más un pequeño bucle de control en tu código que le permite llegar más allá de la conversación. Una vez que el modelo puede llamar a una función que consulta una base de datos, lee un archivo o accede a una API interna, deja de ser un chatbot y empieza a ser capaz de actuar. Los dos caminos siguientes solo difieren en quién aloja las herramientas.
El bucle del agente
Todo agente, sin importar el proveedor, sigue el mismo ciclo:
- Envía el mensaje del usuario junto con una lista de definiciones de herramientas (nombre, descripción, parámetros).
- El modelo o responde en texto plano, o contesta "llama a la herramienta X con estos argumentos".
- Si pide una herramienta, tu código ejecuta el trabajo real y devuelve el resultado.
- El modelo lee el resultado y o llama a otra herramienta o produce la respuesta final.
- Repite hasta que el modelo deja de pedir herramientas.
El modelo nunca ejecuta nada por sí mismo. Solo propone llamadas; tu código Delphi mantiene el control de lo que realmente se ejecuta, que es lo que hace que el patrón sea seguro para ponerlo delante de sistemas reales.
Camino 1: function calling del proveedor
La forma más directa de dar a un único modelo acceso a tu código es la propia API de function calling del proveedor. Declaras las funciones disponibles, el modelo elige una cuando la necesita, y un evento se dispara en tu componente para que puedas proporcionar el resultado. Con el componente de OpenAI defines las herramientas una vez en el asistente, luego manejas la llamada:
Assistant := TsgcAIOpenAIAssistant.Create(nil);
Assistant.OpenAIOptions.ApiKey := 'sk-...';
Assistant.AssistantOptions.Name := 'Delphi Weather Bot';
Assistant.AssistantOptions.Instructions.Text :=
'You are a weather bot. Use the provided functions to answer questions.';
Assistant.AssistantOptions.Model := 'gpt-4o';
// Describe the callable functions as JSON tool definitions
Assistant.AssistantOptions.Tools.Functions.Functions.Text :=
'[{"type":"function","function":{"name":"get_current_temperature",' +
'"description":"Get the current temperature for a specific location",' +
'"parameters":{"type":"object","properties":{"location":{"type":"string"}},' +
'"required":["location"]}}}]';
Cuando el modelo decide que necesita un valor, el componente lanza OnFunctionCall. Inspeccionas aRequest._Function._Name para saber qué herramienta se solicitó y escribes la respuesta en aResponse.Output — ese resultado se devuelve directamente al modelo para que pueda terminar su respuesta:
procedure TForm1.AssistantFunctionCall(Sender: TObject;
const aRequest: TsgcOpenAIClass_ToolCall;
const aResponse: TsgcHTTPOpenAI_ToolCall_Response);
begin
if aRequest._Function._Name = 'get_current_temperature' then
aResponse.Output := 30
else if aRequest._Function._Name = 'get_rain_probability' then
aResponse.Output := 10;
end;
Ese manejador de eventos es el bucle del agente. Cada vez que el modelo pide una herramienta, la ejecutas y devuelves; el componente mantiene la conversación en marcha hasta que el modelo tiene todo lo que necesita. Este camino es ideal cuando el agente vive dentro de tu propia aplicación y habla con un solo proveedor. La misma forma está disponible en los componentes de Anthropic y Gemini, así que no quedas atado. Consulta el recorrido por el function calling de OpenAI para el ejemplo completo.
Camino 2: herramientas MCP
El function calling ata tus herramientas a un modelo en una aplicación. El Model Context Protocol convierte la misma idea en un servicio reutilizable: tu aplicación expone un conjunto de herramientas sobre un endpoint JSON-RPC estándar, y cualquier cliente o agente compatible con MCP — un asistente de IDE, una aplicación de IA de escritorio o tu propio bucle de agente — puede conectarse, descubrir esas herramientas y llamarlas. Escribes la herramienta una vez; cualquier host MCP puede usarla.
En sgcWebSockets el lado del servidor es TsgcWSAPIServer_MCP. Lo conectas a un servidor HTTP de sgcWebSockets, registras herramientas con Tools.AddTool y manejas la llamada entrante en OnMCPRequestTool:
uses
sgcWebSocket_Server, sgcAI, sgcAI_MCP_Classes, sgcAI_MCP_Server;
procedure TForm1.SetupMCPServer;
begin
MCPServer.Server := Server;
MCPServer.EndpointOptions.Endpoint := '/mcp';
MCPServer.MCPOptions.ServerInfo.Name := 'sgc-mcp-server';
MCPServer.MCPOptions.ServerInfo.Version := '1.0.0';
// Register a callable tool with a typed argument
with MCPServer.Tools.AddTool('GetTemperature',
'Get the actual temperature in a city.') do
InputSchema.Properties.AddProperty('city', True);
MCPServer.OnMCPRequestTool := MCPRequestTool;
Server.Port := 8080;
Server.Active := True;
end;
Cuando un cliente conectado llama a la herramienta, el evento se dispara con objetos de petición y respuesta fuertemente tipados. Lees el nombre de la herramienta desde aRequest.Params.Name y sus argumentos desde aRequest.Params.Arguments, luego escribes la respuesta con aResponse.Result.Content.AddText:
procedure TForm1.MCPRequestTool(Sender: TObject;
const aSession: TsgcAI_MCP_Session;
const aRequest: TsgcAI_MCP_Request_ToolsCall;
const aResponse: TsgcAI_MCP_Response_ToolsCall);
begin
if aRequest.Params.Name = 'GetTemperature' then
aResponse.Result.Content.AddText('The current temperature in ' +
aRequest.Params.Arguments.Item[0].Value + ' is 22 Celsius');
end;
El manejador hace el mismo trabajo que el evento de function calling, pero ahora la herramienta es accesible por cualquier host MCP a través de la red. Como MCP es un estándar publicado, el agente que dirige la conversación no tiene por qué estar escrito por ti en absoluto. Lee más en la descripción general de MCP y en la página del componente MCP Server.
¿Qué camino deberías usar?
| Si quieres… | Usa | Componente |
|---|---|---|
| Un agente que vive dentro de tu propia aplicación y habla con un solo proveedor | Function calling del proveedor | TsgcAIOpenAIAssistant |
| Herramientas que cualquier cliente o agente compatible con MCP pueda descubrir y llamar | Servidor MCP | TsgcWSAPIServer_MCP |
| Llamar a herramientas alojadas en el servidor MCP de otra persona | Cliente MCP | TsgcWSAPIClient_MCP |
Los dos no son mutuamente excluyentes. Un diseño común es un agente dentro de la aplicación que usa el function calling del proveedor para sus propias herramientas privadas, mientras también se conecta como cliente MCP a servidores de herramientas compartidas en otros lugares de tu organización. Elijas el que elijas, el bucle que escribes tiene un aspecto casi idéntico, así que moverse entre ellos más adelante es barato.
Primeros pasos
Ambos caminos vienen incluidos en sgcWebSockets (el servidor y el cliente MCP son componentes Enterprise). Consigue la prueba gratuita, coloca un TsgcAIOpenAIAssistant para function calling o un TsgcWSAPIServer_MCP para un servicio MCP, conecta el evento de la herramienta, y tendrás un agente que puede actuar sobre tu propio código en unas pocas líneas. Explora todos los bloques de construcción de IA en el hub de componentes de IA y LLM.
¿Preguntas o quieres ayuda para diseñar tu agente? Ponte en contacto — recibirás una respuesta de las personas que escribieron el código.
