---
slug: hello-stamp
assetPath: /resources/blog/hello-stamp
title: "Stamp: los agentes envían código con su propio nombre"
description: Los agentes envían código con su propia identidad; las personas revisan, aprueban y fusionan en Stamp.
metaDescription: Hoy lanzamos Stamp. Los agentes de Raft lo usan para subir código y abrir pull requests con su propia identidad, y las personas revisan, aprueban y fusionan en Stamp.
categoryKey: product
tagKeys: product, engineering, ax
publishedLabel: 28 de octubre de 2026
author: jiacheng
heroImage: /resources/blog/hello-stamp/hero.png
heroAlt: "Stamp se ubica entre los agentes de Raft y GitHub: los agentes suben código y abren pull requests a través de Stamp"
socialImage: /resources/blog/hello-stamp/hello-stamp-social-1200x630.png
draft: false
canonicalUrl: https://raft.build/es/resources/blog/hello-stamp/
datePublished: 2026-10-28
dateModified: 2026-10-28
---

> Fuente: blog oficial de Raft · https://raft.build/es/resources/blog/hello-stamp/

## Qué es Stamp

Hoy lanzamos **Stamp** ([stamp.build](https://stamp.build)). Los agentes de Raft lo usan para subir código y abrir pull requests: hacen commits con su propia identidad, y las personas revisan, aprueban y fusionan en Stamp. El código sigue en GitHub. Stamp se ubica entre tus agentes y GitHub y cubre lo que GitHub nunca diseñó pensando en agentes.

¿Por qué ese nombre? En inglés, *stamp* significa sello. Antes, los documentos oficiales se sellaban para que cualquiera pudiera ver quién los había tramitado y quién los había autorizado. Stamp pone ese sello en cada push, cada revisión y cada aprobación de un agente: quién lo hizo y a qué versión del código corresponde, todo queda registrado.

Stamp no te pide mudar tu código. El alojamiento, Actions y el escaneo de seguridad siguen en GitHub; Stamp solo rehace la identidad, los permisos, la revisión y las notificaciones. Por ahora Stamp funciona con GitHub, y más adelante se sumarán otras plataformas de alojamiento de código.

## Por qué usar Stamp

Todo el flujo de trabajo de GitHub da por hecho que hay una *persona* frente al teclado: una computadora, una clave SSH, unas pocas ramas al día y alguien que revisa el diff línea por línea. Nuestro equipo no trabaja así. Un puñado de personas tiene a su cargo más de cien agentes siempre activos, repartidos en muchas máquinas y escribiendo código a la vez, y esos supuestos dejan de sostenerse:

- **No sabes qué agente escribió qué.** Los agentes usan prestada la cuenta de una persona o comparten una sola cuenta de bot. Con cientos de pull requests bajo el mismo nombre, las personas no distinguen quién abrió cuál, y un agente que empieza una sesión nueva no logra encontrar sus propios pull requests.
- **El acceso es todo o nada.** Darle tu token personal a un agente no es seguro; sin él, no puede ni subir código ni abrir un pull request.
- **Máquina nueva, push fallido.** Las claves de Git están atadas a una máquina, así que cuando un agente migra a otra, a menudo se queda detenido en `Permission denied`.
- **Nadie puede poner orden en los pendientes.** En los dos meses previos a Stamp, se acumularon casi 600 pull requests sin fusionar en el repositorio principal de Raft. Nadie podía decir si el último commit de cada uno se había revisado, ni si la CI se había ejecutado de verdad o se había saltado.
- **Una vez que sube el código, el agente le pierde la pista.** Si cierran el pull request, alguien deja una revisión o falla la CI, el agente no tiene forma de enterarse. Solo le queda consultar una y otra vez, o esperar a que alguien vuelva a pegar el enlace en el chat.

Stamp nació para resolver estos problemas. Comparado con que los agentes usen GitHub directamente, cambia cuatro cosas: la identidad, el cambio de máquina, la revisión y las notificaciones.

### Cada agente tiene su propia identidad y su propio acceso

Un agente de Raft ejecuta `stamp login` una vez y obtiene su propia identidad y su avatar. A partir de ahí, cada commit, pull request y comentario que hace en GitHub lleva su propio nombre.

En el repositorio público [`raft-builders/awesome-raft-build`](https://github.com/raft-builders/awesome-raft-build/pulls) hay un ejemplo. Nuestro compañero agente `sindresorhus` recorre cada día la comunidad de código abierto y agrega a la lista los proyectos nuevos que cumplen los criterios. Cuando la ronda del 22 de octubre encontró proyectos nuevos, subió por su cuenta la rama `agent/sindresorhus/patrol-2026-10-22b` y abrió el [PR #11](https://github.com/raft-builders/awesome-raft-build/pull/11). En la parte superior del pull request aparecen su avatar de píxeles y la línea «sindresorhus from raft opened this pull request through Stamp», y los commits también llevan su avatar. Cuando pasaron las comprobaciones, `stamp-build` lo fusionó automáticamente. En ningún momento nadie prestó su cuenta.

![Agent sindresorhus 用自己的身份在公开仓库开出 PR #11，检查通过后由 Stamp 自动合入。](/resources/blog/hello-stamp/awesome-raft-pr.png)

*El agente sindresorhus abrió el PR #11 en un repositorio público con su propia identidad; Stamp lo fusionó cuando pasaron las comprobaciones.*

En la máquina del agente tampoco hay un token de GitHub. Cuando sube código, Stamp primero verifica que quien hace el commit sea de verdad ese agente y que el push no toque ramas protegidas ni configuración sensible. Solo entonces lo sube a GitHub y le entrega al agente un recibo. El agente abre su pull request con ese recibo; si un push se bloquea o falla, el recibo dice por qué y cuándo reintentar, así que nada falla en silencio.

Cuando un agente necesita acceso a un repositorio nuevo, o tiene que lanzar una compilación, no te pide una clave. Publica en el chat una tarjeta de solicitud de permiso; tú eliges el alcance y la duración (por ejemplo, 7 días, 30 días o solo esta vez), haces clic en Aprobar y el permiso entra en vigor. Si haces clic en Revocar para retirarlo, deja de funcionar al instante.

![推送先经过 Stamp 的检查；需要新权限时，Agent 在聊天里发申请卡，由人批准。](/resources/blog/hello-stamp/permission-request-flow.png)

*Cada push pasa primero por las comprobaciones de Stamp; si necesita un acceso nuevo, el agente envía una tarjeta de solicitud y una persona la aprueba.*

### Cambia de máquina sin volver a configurar el acceso

Antes, el acceso a Git vivía en el `~/.ssh` de una máquina. Cuando un agente pasaba a otra, alguien tenía que copiar las claves y volver a configurar el entorno.

En Stamp, el acceso a los repositorios pertenece a la identidad de Raft del agente, no a una máquina. Sea cual sea la máquina a la que se asigne el agente, su acceso a los repositorios, sus aprobaciones y sus permisos temporales lo acompañan. En una máquina nueva, ejecuta `stamp login` una vez y se autentica con la sesión de Raft que ya tiene abierta, sin copiar claves privadas. Cuando una máquina vieja se desconecta, puedes cerrar la sesión solo en esa máquina sin afectar el trabajo del agente en ningún otro lugar.

![仓库权限属于 Agent 的 Raft 身份，Agent 换到哪台机器上都有效。](/resources/blog/hello-stamp/roaming-identity.png)

*El acceso a los repositorios pertenece a la identidad de Raft del agente, así que funciona en cualquier máquina donde se ejecute.*

### Lo que se fusiona es lo que se revisó

Los agentes escriben código mucho más rápido de lo que las personas pueden leerlo, así que la revisión tiene que funcionar de otra manera. La primera pregunta al abrir un pull request es: ¿se puede fusionar ahora mismo?

La página de revisión de Stamp pone esa respuesta arriba de todo. Abre un pull request en Stamp, o reemplaza `github.com` por `github.stamp.build` en cualquier enlace de un pull request de GitHub, y llegas a su página de revisión. Cada aprobación, venga de un agente o de una persona, vale solo para el commit sobre el que se dio: con un nuevo push a la rama, las aprobaciones anteriores dejan de contar. Así nunca revisas una versión y fusionas otra. Si se saltó una comprobación de CI obligatoria, la página también lo indica.

![Stamp 的审查页：最上方是能不能合入的结论，下面是反向验证的记录。](/resources/blog/hello-stamp/review-desk-verdict.png)

*La página de revisión de Stamp: arriba, si se puede fusionar; debajo, el registro de la verificación inversa.*

La revisión del día a día no tiene que esperar a una persona cada vez. El agente autor puede pedirle a un subagente completamente nuevo que revise el código de forma independiente, y adjuntar el registro de esa revisión. Stamp exige que el registro incluya una **verificación inversa**: quitar temporalmente la corrección para que el bug vuelva y confirmar que la prueba nueva falla, y luego volver a poner la corrección y ver que la prueba pasa. Eso demuestra que la prueba de verdad detecta el problema. Cuando un cambio toca rutas sensibles, como migraciones de base de datos o la configuración de CI, el autor no puede aprobarlo solo; tiene que revisarlo otro agente o una persona.

Si envías el enlace de un pull request a un canal o a un mensaje directo de Raft, se abre como una tarjeta de estado en tiempo real, así que puedes ver el estado y decidir sin salir del chat.

![Stamp 的 PR 链接发进 Raft 频道后，展开成实时更新的状态卡片：审查、CI、自动合入，以及还差什么。](/resources/blog/hello-stamp/stamp-card-in-raft.png)

*Un enlace de PR de Stamp enviado a un canal de Raft se abre como una tarjeta de estado en vivo: revisión, CI, fusión automática y lo que aún falta.*

Así, la mayoría de las revisiones ocurren entre agentes, y las personas solo intervienen donde importa. De las **6,962 aprobaciones de pull requests** que nuestro equipo ha hecho en Stamp, **6,892 vinieron de agentes y 70 de personas**.

### Cuando un PR cambia, el agente se entera

En Stamp, cada pull request sabe qué agente lo escribió. Un agente puede listar en cualquier momento todos sus pull requests abiertos, ordenados según a quién le toca actuar: los que tienen la CI por arreglar, los que esperan la revisión de alguien más y los que ya se pueden fusionar.

Cuando alguien deja una revisión, falla la CI o se fusiona un pull request, Stamp filtra el ruido y despierta al agente que corresponde a través de `stamp inbox`. En los últimos 30 días, Stamp envió **8,341** de estos avisos en nuestro equipo. Los comentarios de desconocidos en repositorios públicos se marcan como no confiables y no despiertan al agente, así que nadie puede usar un comentario para darle instrucciones a tu agente.

![PR 有变化时，Stamp 通过收件箱叫醒对应的 Agent；外部评论不会叫醒它。](/resources/blog/hello-stamp/agent-inbox-awareness.png)

*Cuando un PR cambia, Stamp despierta al agente que lo creó a través de su bandeja de entrada; los comentarios externos no lo despiertan.*

Después de abrir un pull request, un agente puede activar la fusión automática y seguir con otro trabajo. En una rama principal con mucho movimiento, la cola de fusión de Stamp prueba juntos varios pull requests ya revisados y saca el que rompa la compilación. Y si tu equipo tiene varios servidores de Raft, trabajan juntos de forma predeterminada siempre que sus instalaciones de Stamp compartan una misma organización de GitHub (a esto lo llamamos Joint), sin nada adicional que configurar: una aprobación en un lado cuenta en el otro, y las listas de pull requests, la búsqueda y la cola de fusión son compartidas.

## Qué cambió desde que lo adoptamos

Antes del lanzamiento, pasamos a todo nuestro equipo a Stamp.

En los últimos 30 días, **161 agentes** y **13 compañeros humanos** usaron Stamp. En el último mes, en nuestra organización `botiverse`, los agentes subieron código **12,532 veces** en **5 servidores de Raft** y **151 repositorios**. Sin contar los pushes que frenaron las reglas o los permisos, el **99.8%** llegó a GitHub. Abrieron **6,311 pull requests**, y **5,661** ya se fusionaron, casi nueve de cada diez.

Una semana después del cambio, el 94% de los pull requests del repositorio principal de Raft se abría a través de Stamp.

![接入 Stamp 前后：每周合入的 PR 数，以及较慢那四分之一 PR 从开出到合入的时间（p75）。](/resources/blog/hello-stamp/before-after-metrics.png)

*Antes y después de Stamp: PR fusionados por semana y el tiempo de espera del cuarto más lento de los PR (p75).*

El mayor cambio es que los pull requests ya no se acumulan. La cuarta parte más lenta de los pull requests (p75) solía esperar de dos a tres horas desde que se abría hasta que se fusionaba, y algunos nunca recibían seguimiento. Con los avisos en tiempo real y la fusión automática, esa espera bajó en el repositorio principal de **2.7 horas a 31 minutos** (5.2 veces más rápido), en el cliente móvil de **3.6 horas a 1.1 horas** (3.3 veces) y en el repositorio de Stamp de **1.3 horas a 36 minutos** (2.2 veces). A medida que crecían el equipo y sus agentes, la cantidad de pull requests fusionados por semana en estos tres repositorios llegó a ser de **2.5 a 5.3 veces** la de antes: el repositorio principal pasó de 250 por semana a 618, y después de la primera semana, a 681 por semana.

## Cómo empezar

La compatibilidad de Stamp con GitHub ya está disponible en [stamp.build](https://stamp.build).

Configurarlo toma menos de 15 minutos:

1. Inicia sesión en [stamp.build](https://stamp.build) con tu cuenta de Raft, elige un servidor e instala Stamp (tienes que ser propietario o administrador del servidor), y luego conecta tus repositorios de GitHub (consulta la [guía de inicio rápido](https://docs.stamp.build/get-started/), en inglés).
2. Envía [`https://stamp.build/llms.txt`](https://stamp.build/llms.txt) a tu agente de Raft. Instala la herramienta de línea de comandos, inicia sesión y sube su primera rama por su cuenta.
3. Cuando el agente abra un pull request, haz clic en el enlace de Stamp que publica en tu canal de Raft (o reemplaza `github.com` por `github.stamp.build` en el enlace del pull request de GitHub) para revisarlo y fusionarlo.

Deja que tus agentes escriban el código. El criterio y las decisiones siguen en tus manos.