# How to Build an Agent Platform
**作者**: Ashpreet Bedi
**日期**: 2026-05-07T15:43:19.000Z
**来源**: [https://x.com/ashpreetbedi/status/2052413981487427871](https://x.com/ashpreetbedi/status/2052413981487427871)
---
Cloud platforms, data platforms, and now agent platforms.
Every company wants to build one and run a fleet of agents. Having built cloud, compute and data platforms before, I'm hoping we can learn from the mistakes of our past and build it right the first time 'round.
The data era is a particularly cautionary tale. I lived through the great unbundling where we had to stitch multiple tools for ingestion, orchestration, transformation, and services for metadata, BI, and data quality. Each tool worked great in isolation but using them together was a pain. 80% of engineering time went into gluing things together. Then came the bundling. Snowflake, Databricks, and the cloud providers (esp AWS) consolidated the stack and provided unified platforms.
The agent era is starting the same way, with features being sold as products and vendors for solving problems that don't really exist yet.
If you find yourself running agents with data on 3 providers, traces in multiple places and no auto-improvement loop, this article is for you.
## You need an agent platform
If you think of agents as apps, it becomes clear that they need a system to run on, like an OS.
Your agent platform is responsible for running the agents, collecting data and metrics, managing security by preventing unauthorized access, and stopping one agent from accessing or polluting the data of another.
## What we're building
Today we'll build an agent platform that you can run locally, or on Railway for $20/mo.
Once it's running, you should be able to ship a new agent (or workflow) without writing any code. Because the platform takes care of everything, claude code can build new agents with a high degree of quality, and then recursively improve them by querying them live. This is the single biggest advantage of having a unified agent platform.
We'll also set up a scheduler for recurring work, lock in behavior with evals, and connect agents to interfaces like Slack.
The most fun is watching claude code recursively improve your agents.
## What makes an agent platform
An agent platform is made of five parts:
1. Runtime: the service that runs the agents. This part does most of the heavy lifting.
2. Storage: the database where our data lives: agent sessions, memory, knowledge, traces and eval history.
3. Connectors: tools for agents to connect with external systems via MCP, API, or CLI. Having them in one place is a big + for security.
4. Interfaces: Slack, Discord, Telegram, custom UIs. One place to resolve identity across surfaces, so the same person is the same user_id whether they ping you in Slack or hit the web app.
5. Infrastructure: where everything runs. We'll use Docker for local and Railway for production.
## Let's get started
I'm going to share a foundational codebase that you can build upon.
This, in my opinion, is the perfect starting point for an agent platform.
```
agent-platform
├── agents # agent code goes here
│ ├── code_search.py
│ └── web_search.py
├── app # server code goes here
│ ├── config.yaml
│ ├── main.py
│ └── settings.py
├── compose.yaml
├── db
│ ├── session.py
│ └── url.py
├── Dockerfile
├── docs # docs go here
│ ├── create-new-agent.md
│ ├── eval-and-improve.md
│ ├── improve-agent.md
│ └── review-and-improve.md
├── evals
│ └── cases.py # test cases
└── README.md
```
## Step 1: Run locally
First let's clone, configure, and run our agent platform.
Make sure Docker is installed and running. Follow these steps if not.
Then open your terminal and run one by one:
1. Clone the agent-platform template
```
git clone https://github.com/agno-agi/agentos-railway-template.git agent-platform
cd agent-platform
```
2. Configure your environment. Copy the example .env file, open in your favorite code editor and add the OpenAI key there.
```
cp example.env .env
```
3. Run your platform: 1 FastAPI server and 1 Postgres database
```
docker compose up -d --build
```
This brings up two containers: a FastAPI server and a Postgres database. Confirm the API is running at http://localhost:8000/docs.
Now let's give our platform a UI.
1. Head to os.agno.com and sign in.
2. Connect to your local OS at http://localhost:8000.
You should see something like:
## Step 2: Create your first agent
The codebase comes with two reference agents and a Claude Code prompt that can build new ones for you.
To create a new agent, open Claude Code and run
```
Run docs/create-new-agent.md
```
Claude will ask you what the agent should do, what tools it needs, then generate the agent file, register it in app/main.py, restart the container, and run a smoke test.
This usually takes 5-10 minutes for a simple agent. More if you're building something bespoke with custom tools.
## Step 3: Test your new agent
Open os.agno.com to chat with your agent. Run it through realistic prompts. Check the traces and sessions. Try to break it. Try out-of-distribution questions, prompt injections, edge cases. This usually takes 5-20 minutes.
## Step 4: Recursively improve your agent
This is where your platform starts paying dividends.
Open Claude Code in the repo and paste:
```
Run docs/improve-agent.md
```
Claude Code can directly hit your live agents using curl. Then iterate and improve your agents.
This is why owning the stack pays off. The trace data, the agent code, the running platform, and the iteration tool all live in one box. Claude Code can see all of it and improve as needed.
## Step 5: Lock in behavior with evals
Evals are the regression test for your agents. Same prompts, same agents, run on a schedule, fail when behavior drifts.
Evals are defined as a set of cases:
```
# evals/cases.py
Case(
name="web_search_recent_anthropic_research",
agent=web_search,
input="What did Anthropic publish about agent research recently?",
criteria=(
"Answers the question by citing at least one real Anthropic URL "
"(anthropic.com domain). The response is grounded in fetched content "
"rather than refusing to answer."
),
expected_tool_calls=(_WEB_SEARCH_TOOL,),
)
```
Run them later with: python -m evals
Results write to your Postgres via eval_db, so eval history shows up at os.agno.com alongside sessions and traces.
Connect Claude Code to the diagnosis loop by pasting Run docs/eval-and-improve.md. It triages every failure and fixes the issues in scope.
## Step 6: Run on Railway
Let's take our platform live by hosting it somewhere. Your company probably has a set way of running software. Follow whatever that is.
If you're looking for a place to test this out without going through the full devops process, Railway is the cheapest and fastest PaaS I've found. $20/month gets you pretty far and the codebase already comes with deploy-to-railway scripts.
> Requires the Railway CLI and railway login.
6.1 Configure production environment
The deploy scripts read .env.production first and fall back to .env. This lets you keep separate values for local and production: different OpenAI keys with different budgets, production-only credentials, a different Slack workspace, and so on.
```
cp .env .env.production
# Edit .env.production with production values
```
6.2 Deploy
The codebase comes with a script that provisions a Postgres database and deploys the app on the same private network. Run it:
```
./scripts/railway/up.sh
```
6.3 Your first deploy will fail. That's expected.
Token-Based Authorization is ON by default.
Without a JWT_VERIFICATION_KEY, the app refuses to serve traffic. Your platform's job is to keep your data off the public web. The fix is to generate a key and put it in your production env.
> The alternative was to ship with auth off and expect people to add it on later, which we all know isn't going to happen. People will leave their servers open to the public internet, get hacked, then blame me.
Token-Based Auth gives you three things:
- No public access. The server rejects requests without a valid token.
- Per-request identity. The middleware parses the token and injects user_id, session_id, and custom claims into your endpoints. Each request is tied to a user and session, so data leakage is prevented.
- Granular permissions. A user-level token can run an agent and view its own sessions. An admin token can read everyone's sessions and test any agent. You don't need to know or care about RBAC right now, but you have the foundation in place for when you start thinking about security.
6.4 Get your verification key
The default path is to let os.agno.com generate the key pair for you:
1. Open os.agno.com, click Add OS → Live, enter your Railway domain
2. Enable Token Based Authorization and then connect.
3. Paste the public key into .env.production.
```
JWT_VERIFICATION_KEY=-----BEGIN PUBLIC KEY-----
MIIBIjANBgkq...
-----END PUBLIC KEY-----
```
> Live connections to AgentOS require a pro subscription. Use the PLATFORM30 coupon code for a 1 month free trial. Remember to cancel before the trial ends if you don't want to be charged.
FYI: You don't have to use os.agno.com for this. You can generate your own RSA or EC keypair, sign tokens with the private key in your own service, and put the matching public key in JWT_VERIFICATION_KEY. The platform doesn't care where the key came from, as long as incoming tokens verify.
6.5 Sync env and verify
While .env.production is open, point the in-cluster scheduler at your public Railway domain so cron triggers can reach AgentOS:
```
# .env.production
AGENTOS_URL=https://<your-app>.up.railway.app
```
Then push variables to Railway:
```
./scripts/railway/env-sync.sh
```
Railway auto-deploys when env values change. Watch the logs and confirm the platform is serving:
```
railway logs --service agent-os
```
Once you see successful requests, AgentOS will connect through your Railway domain and you're live.
6.6 Auto-deploys from GitHub
So far every code update needs ./scripts/railway/redeploy.sh.
To auto-deploy on push to main:
1. Open the Railway dashboard → your project → the agent-os service → Settings.
2. Under Source, click Connect Repo and pick your repo.
3. Set the deploy branch to main.
Every push to main now triggers a build and rolling deploy. ./scripts/railway/env-sync.sh is still how you sync env changes.
Opting out of JWT (not recommended)
If you must run production without auth (e.g., inside a private VPC behind another auth layer), set authorization=False in app/main.py and redeploy. Keep authorization on for any deploy holding real data. Without it, anyone who guesses your Railway domain can read your sessions and your agents.
Scaling
The default deploy is two replicas at 4Gi memory and 2 vCPU each. Gives you zero-downtime rolling deploys and basic fault tolerance. Bump numReplicas and limits up or down in railway.json as your usage grows.
## Going beyond agents
Rule of thumb: agents for open questions, teams for routing, workflows for processes. Most of your platform will be agents. A few will be teams or workflows. You'll know when you need each.
Multi-agent teams. When one agent isn't enough, route work across a team of specialists. Agno teams come in three modes:
- Coordinate. A leader plans the work, calls the right specialists, and synthesizes.
- Route. A router picks one specialist to handle the request.
- Broadcast. Every specialist runs in parallel; you aggregate.
Use teams when the right specialist isn't known up front. The teams overview walks through each mode.
Agentic workflows. When a process needs to run the same way every time, write a workflow. Workflows give you determinism. Use them for the few high-leverage flows in your platform that need to be repeatable. The workflows overview covers the patterns.
For more on agents themselves (instructions, tools, memory, model configuration), the agents overview is the reference.
## Scheduled tasks
The platform ships with a lightweight scheduler enabled by default in app/main.py:
```
agent_os = AgentOS(
name="AgentOS",
scheduler=True,
...
)
```
Schedule any agent or workflow on a cron. Common patterns:
- Maintenance. Purge sessions older than 90 days. Vacuum your Postgres tables. Rotate trace data into cold storage.
- Proactive runs. Every weekday morning, run an agent that summarizes overnight news for your portfolio companies. Post to Slack.
- Catch regressions. Schedule python -m evals weekly against your production agents. Drift shows up in eval history before users feel it.
See the agno scheduler docs for the cron API.
## Connect to interfaces
Your agents should be available where your users are. Slack threads. Discord channels. Telegram for the field team.
Or most importantly: a custom UI inside your product.
For slack, discord, telegram: the pattern is similar. Expose the agents via an interface. See app/main.py for a reference:
```
interfaces: list = []
if SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET:
from agno.os.interfaces.slack import Slack
interfaces.append(
Slack(
agent=code_search,
streaming=True,
token=SLACK_BOT_TOKEN,
signing_secret=SLACK_SIGNING_SECRET,
resolve_user_identity=True,
)
)
...
agent_os = AgentOS(
...
interfaces=interfaces,
)
```
Read the interfaces guide for more information.
## Wrapping up
Congratulations. If you made it this far, you have a unified agent platform running securely in your cloud. Technical users can create and deploy agents using Claude Code. Non-technical users can use the no-code UI.
Sessions, traces, and knowledge live in your database. Your infrastructure is gated behind JWT-based RBAC and API keys are managed in one place.
## Why it's important to control your data
Before we close, a note on data sovereignty.
Every interaction with your platform produces data. Sessions, memory, and traces all flow into your Postgres database. Two reasons why this matters:
1. Compliance. Keeping the data in your own database reduces the risk of a breach. The moment customer data, proprietary code, or internal documents touch a third-party trace tool or memory service, your level of security is whatever their level of security is.
2. Auto Improvement. Your traces are how Claude Code (or you) close the loop on agent quality. Coding agents are going to be the main way to build and improve agents. They can only work because the trace data lives where the iteration tool can read it. Vendor-stitched stacks split this surface across three SaaS products and the loop never closes.
The agents you ship today are the smallest part of what you've built. The platform underneath them, and the iteration loop it enables, is the thing that matters.
Thanks for reading. Built with 🧡 using Agno.
## 相关链接
- [Ashpreet Bedi](https://x.com/ashpreetbedi)
- [@ashpreetbedi](https://x.com/ashpreetbedi)
- [33K](https://x.com/ashpreetbedi/status/2052413981487427871/analytics)
- [Follow these steps](https://www.docker.com/get-started/)
- [http://localhost:8000/docs](http://localhost:8000/docs)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [Railway CLI](https://docs.railway.com/cli#installing-the-cli)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [teams overview](https://docs.agno.com/teams/overview)
- [workflows overview](https://docs.agno.com/workflows/overview)
- [agents overview](https://docs.agno.com/agents/overview)
- [agno scheduler docs](https://docs.agno.com/agent-os/scheduler)
- [interfaces guide](https://docs.agno.com/agent-os/interfaces/overview)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:43 PM · May 7, 2026](https://x.com/ashpreetbedi/status/2052413981487427871)
- [33.4K Views](https://x.com/ashpreetbedi/status/2052413981487427871/analytics)
- [View quotes](https://x.com/ashpreetbedi/status/2052413981487427871/quotes)
---
*导出时间: 2026/5/8 13:31:50*
---
## 中文翻译
# 如何构建一个 Agent 平台
**作者**: Ashpreet Bedi
**日期**: 2026-05-07T15:43:19.000Z
**来源**: [https://x.com/ashpreetbedi/status/2052413981487427871](https://x.com/ashpreetbedi/status/2052413981487427871)
---
云平台、数据平台，现在又有了 Agent 平台。
每家公司都想构建一个平台并运行一批 agent。由于之前构建过云计算和数据平台，我希望我们能够吸取过去的教训，一次就把事情做对。
数据时代是一个特别值得警惕的教训。我亲身经历了大拆分时代，当时我们不得不拼接多个工具来完成摄取、编排、转换，以及元数据、BI 和数据质量服务。每个工具单独使用都很出色，但把它们放在一起使用却非常痛苦。80% 的工程时间都花在了把这些东西粘合在一起上。随后迎来了整合时代。Snowflake、Databricks 和云服务提供商（尤其是 AWS）整合了技术栈，提供了统一的平台。
Agent 时代正在以同样的方式开始，功能被当作产品出售，供应商在解决一些尚不存在的问题。
如果你发现自己在 3 个提供商上运行 agent，追踪数据分散在多处，而且没有自动改进循环，那么这篇文章就是为你准备的。
## 你需要一个 Agent 平台
如果你把 agent 视为应用，那么很显然它们需要一个运行系统，就像操作系统一样。
你的 Agent 平台负责运行 agent、收集数据和指标、通过阻止未经授权的访问来管理安全性，并防止一个 agent 访问或污染另一个 agent 的数据。
## 我们要构建什么
今天我们将构建一个可以在本地运行的 Agent 平台，也可以部署到 Railway 上，每月只需 20 美元。
一旦运行起来，你应该能够无需编写任何代码就发布一个新的 agent（或工作流）。因为平台负责一切，Claude Code 能够以高质量构建新 agent，然后通过实时查询来递归地改进它们。这是拥有统一 Agent 平台的最大优势。
我们还将设置一个调度器来处理周期性任务，通过评估锁定行为，并将 agent 连接到 Slack 等接口。
最有趣的部分就是看着 Claude Code 递归地改进你的 agent。
## Agent 平台的构成
一个 Agent 平台由五个部分组成：
1. 运行时（Runtime）：运行 agent 的服务。这部分承担了大部分繁重的工作。
2. 存储（Storage）：存放数据的数据库：agent 会话、记忆、知识、追踪和评估历史。
3. 连接器（Connectors）：供 agent 通过 MCP、API 或 CLI 连接外部系统的工具。将它们集中在一处对安全性大有裨益。
4. 接口（Interfaces）：Slack、Discord、Telegram、自定义 UI。在一个地方解决跨界面的身份问题，这样同一个人无论在 Slack 上联系你还是访问 Web 应用，都是同一个 user_id。
5. 基础设施（Infrastructure）：一切运行的地方。我们将使用 Docker 运行在本地，使用 Railway 作为生产环境。
## 开始吧
我将分享一个基础代码库，你可以在其之上进行构建。
在我看来，这是 Agent 平台的完美起点。
```
agent-platform
├── agents # agent 代码放在这里
│ ├── code_search.py
│ └── web_search.py
├── app # 服务器代码放在这里
│ ├── config.yaml
│ ├── main.py
│ └── settings.py
├── compose.yaml
├── db
│ ├── session.py
│ └── url.py
├── Dockerfile
├── docs # 文档放在这里
│ ├── create-new-agent.md
│ ├── eval-and-improve.md
│ ├── improve-agent.md
│ └── review-and-improve.md
├── evals
│ └── cases.py # 测试用例
└── README.md
```
## 第 1 步：本地运行
首先，让我们克隆、配置并运行我们的 Agent 平台。
确保已安装并运行 Docker。如果没有，请按照这些步骤操作。
然后打开终端，依次运行：
1. 克隆 agent-platform 模板
```
git clone https://github.com/agno-agi/agentos-railway-template.git agent-platform
cd agent-platform
```
2. 配置你的环境。复制示例 .env 文件，在你喜欢的代码编辑器中打开并添加 OpenAI 密钥。
```
cp example.env .env
```
3. 运行你的平台：1 个 FastAPI 服务器和 1 个 Postgres 数据库
```
docker compose up -d --build
```
这会启动两个容器：一个 FastAPI 服务器和一个 Postgres 数据库。确认 API 正在 http://localhost:8000/docs 运行。
现在让我们给平台加上一个 UI。
1. 访问 os.agno.com 并登录。
2. 连接到你的本地 OS：http://localhost:8000。
你应该会看到类似这样的界面：
## 第 2 步：创建你的第一个 agent
代码库自带两个参考 agent 和一个 Claude Code 提示，可以为你构建新的 agent。
要创建一个新 agent，打开 Claude Code 并运行：
```
Run docs/create-new-agent.md
```
Claude 会询问你 agent 应该做什么、需要哪些工具，然后生成 agent 文件、在 app/main.py 中注册、重启容器，并运行冒烟测试。
对于一个简单的 agent，这通常需要 5-10 分钟。如果你要使用自定义工具构建定制的东西，则需要更长时间。
## 第 3 步：测试你的新 agent
打开 os.agno.com 与你的 agent 聊天。用真实的提示语运行它。检查追踪和会话。试着让它出错。尝试分布外的问题、提示注入、边界情况。这通常需要 5-20 分钟。
## 第 4 步：递归地改进你的 agent
这就是你的平台开始产生回报的地方。
在代码库中打开 Claude Code 并粘贴：
```
Run docs/improve-agent.md
```
Claude Code 可以直接使用 curl 访问你的实时 agent，然后迭代并改进你的 agent。
这就是拥有整个技术栈的回报所在。追踪数据、agent 代码、运行中的平台和迭代工具都集中在一处。Claude Code 可以看到所有内容，并按需进行改进。
## 第 5 步：通过评估锁定行为
评估集是你智能体的回归测试。同样的提示词、同样的智能体，按计划定期运行，当行为发生漂移时就会失败。
评估集被定义为一组测试用例：
```
# evals/cases.py
Case(
name="web_search_recent_anthropic_research",
agent=web_search,
input="What did Anthropic publish about agent research recently?",
criteria=(
"Answers the question by citing at least one real Anthropic URL "
"(anthropic.com domain). The response is grounded in fetched content "
"rather than refusing to answer."
),
expected_tool_calls=(_WEB_SEARCH_TOOL,),
)
```
之后可以通过以下命令运行：python -m evals
结果会通过 eval_db 写入你的 Postgres，因此评估历史会显示在 os.agno.com 上，与会话和追踪信息并列。
将 Claude Code 连接到诊断循环，只需粘贴：Run docs/eval-and-improve.md。它会对每个失败进行分类并修复范围内的问题。
## 第 6 步：在 Railway 上运行
让我们把平台部署到某个地方上线。你的公司可能已有一套固定的软件运行方式，照着做即可。
如果你想找一个不用走完整 devops 流程就能测试的地方，Railway 是我找到的最便宜、最快的 PaaS。每月 20 美元就能用很久，而且代码库已经自带部署到 Railway 的脚本。
> 需要 Railway CLI 并执行 railway login。
6.1 配置生产环境
部署脚本会先读取 .env.production，找不到时回退到 .env。这让你可以为本地和生产环境保留不同的配置值：不同预算的 OpenAI 密钥、仅生产环境使用的凭证、不同的 Slack 工作区等等。
```
cp .env .env.production
# Edit .env.production with production values
```
6.2 部署
代码库附带一个脚本，用于开通 Postgres 数据库并将应用部署在同一私有网络上。运行它：
```
./scripts/railway/up.sh
```
6.3 你的首次部署会失败。这是预期行为。
基于令牌的授权默认开启。
如果没有 JWT_VERIFICATION_KEY，应用会拒绝提供流量服务。你的平台职责就是不让你的数据暴露在公共网络上。解决办法是生成一个密钥并放入你的生产环境变量中。
> 另一种选择是默认关闭认证上线，然后指望人们之后自己加上——我们都知道这不会发生。人们会让服务器对公共互联网敞开，被黑掉，然后怪我。
基于令牌的认证给你带来三件事：
- 无公共访问。服务器会拒绝没有有效令牌的请求。
- 每请求身份识别。中间件解析令牌并将 user_id、session_id 和自定义声明注入到你的端点中。每个请求都与用户和会话绑定，从而防止数据泄露。
- 细粒度权限。用户级令牌可以运行智能体并查看自己的会话。管理员令牌可以读取所有人的会话并测试任何智能体。你现在不需要了解或关心 RBAC，但基础已经就位，等你开始考虑安全问题时就能用上。
6.4 获取你的验证密钥
默认路径是让 os.agno.com 为你生成密钥对：
1. 打开 os.agno.com，点击 Add OS → Live，输入你的 Railway 域名
2. 启用 Token Based Authorization 然后连接。
3. 将公钥粘贴到 .env.production。
```
JWT_VERIFICATION_KEY=-----BEGIN PUBLIC KEY-----
MIIBIjANBgkq...
-----END PUBLIC KEY-----
```
> 连接 AgentOS 的 Live 连接需要 pro 订阅。使用 PLATFORM30 优惠码可获得 1 个月免费试用。如果你不想被扣费，记得在试用结束前取消。
供参考：你不必为此使用 os.agno.com。你可以生成自己的 RSA 或 EC 密钥对，用你自己的服务中的私钥签署令牌，并将匹配的公钥放入 JWT_VERIFICATION_KEY。平台不在乎密钥来自哪里，只要传入的令牌能通过验证即可。
6.5 同步环境变量并验证
在 .env.production 打开时，将集群内调度器指向你的公共 Railway 域名，以便 cron 触发器能够访问 AgentOS：
```
# .env.production
AGENTOS_URL=https://<your-app>.up.railway.app
```
然后将变量推送到 Railway：
```
./scripts/railway/env-sync.sh
```
环境变量变化时 Railway 会自动部署。查看日志并确认平台正在提供服务：
```
railway logs --service agent-os
```
一旦你看到成功的请求，AgentOS 就会通过你的 Railway 域名连接，你就正式上线了。
6.6 从 GitHub 自动部署
到目前为止，每次代码更新都需要运行 ./scripts/railway/redeploy.sh。
要在推送到 main 分支时自动部署：
1. 打开 Railway 仪表板 → 你的项目 → agent-os 服务 → Settings。
2. 在 Source 下，点击 Connect Repo 并选择你的仓库。
3. 将部署分支设置为 main。
现在每次推送到 main 都会触发构建和滚动部署。./scripts/railway/env-sync.sh 仍然是同步环境变量变更的方式。
退出 JWT（不推荐）
如果你必须在没有认证的情况下运行生产环境（例如，在另一个认证层之后的私有 VPC 内），请在 app/main.py 中设置 authorization=False 并重新部署。任何持有真实数据的部署都应保持授权开启。否则，任何猜到你 Railway 域名的人都可以读取你的会话和你的智能体。
扩容
默认部署是两个副本，每个副本 4Gi 内存和 2 vCPU。这为你提供了零停机滚动部署和基本的容错能力。随着使用量增长，可在 railway.json 中上下调整 numReplicas 和限制。
## 超越智能体
经验法则：开放性问题用智能体，路由用团队，流程用工作流。你的平台大部分将是智能体，少部分是团队或工作流。你需要时自然会知道该用哪个。
多智能体团队。当一个智能体不够用时，将工作路由给一个专家团队。Agno 团队有三种模式：
- 协调。领导者规划工作，调用合适的专家，并进行综合。
- 路由。路由器选择一名专家来处理请求。
- 广播。每个专家并行运行；由你汇总结果。
当前置信息中无法提前确定合适的专业人员时，请使用团队。团队概览介绍了每种模式。
代理式工作流。当一个流程需要每次都以相同的方式运行时，就编写一个工作流。工作流为你提供确定性。请将它们用于平台中少数需要可重复执行的高杠杆流程。工作流概览涵盖了相关模式。
关于代理本身的更多内容（指令、工具、记忆、模型配置），代理概览是参考文档。
## 定时任务
平台自带一个轻量级调度器，默认在 app/main.py 中启用：
```
agent_os = AgentOS(
name="AgentOS",
scheduler=True,
...
)
```
可以使用 cron 调度任何代理或工作流。常见模式：
- 维护。清除超过 90 天的会话。对 Postgres 表执行 vacuum。将追踪数据轮转至冷存储。
- 主动运行。每个工作日早上，运行一个代理，为你的投资组合公司总结隔夜新闻。并发布到 Slack。
- 捕获回归。每周对生产环境中的代理调度运行 python -m evals。在用户受影响之前，性能漂移就会在评估历史中显现。
cron API 详情请参阅 agno 调度器文档。
## 连接到界面
你的代理应该出现在用户所在之处。Slack 线程、Discord 频道、外勤团队用的 Telegram。
或者最重要的是：你产品内的自定义 UI。
对于 Slack、Discord、Telegram，模式都是类似的。通过一个界面暴露代理。参考 app/main.py 中的示例：
```
interfaces: list = []
if SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET:
from agno.os.interfaces.slack import Slack
interfaces.append(
Slack(
agent=code_search,
streaming=True,
token=SLACK_BOT_TOKEN,
signing_secret=SLACK_SIGNING_SECRET,
resolve_user_identity=True,
)
)
...
agent_os = AgentOS(
...
interfaces=interfaces,
)
```
更多信息请阅读界面指南。
## 总结
恭喜。如果你读到了这里，说明你已经拥有一个在自家云环境中安全运行的统一代理平台。技术用户可以使用 Claude Code 创建和部署代理。非技术用户可以使用无代码 UI。
会话、追踪和知识都存储在你的数据库中。你的基础设施受基于 JWT 的 RBAC 保护，API 密钥在一处统一管理。
## 为什么掌控自己的数据很重要
在结束之前，谈一谈数据主权。
与平台的每一次交互都会产生数据。会话、记忆和追踪都会流入你的 Postgres 数据库。这一点之所以重要，有两个原因：
1. 合规。将数据保存在自己的数据库中可以降低泄露风险。一旦客户数据、专有代码或内部文档触及第三方追踪工具或记忆服务，你的安全水平就取决于他们的安全水平。
2. 自动改进。追踪数据是 Claude Code（或你）闭环改进代理质量的依据。编程代理将成为构建和改进代理的主要方式。它们之所以能工作，是因为追踪数据存放在迭代工具可以读取的地方。供应商拼凑的堆栈将这一环节分散到三个 SaaS 产品中，闭环永远无法完成。
你今天发布的代理只是你所构建成果中最小的部分。它们底下的平台，以及平台所支持的迭代闭环，才是真正重要的东西。
感谢阅读。使用 Agno 以 🧡 构建。
## 相关链接
- [Ashpreet Bedi](https://x.com/ashpreetbedi)
- [@ashpreetbedi](https://x.com/ashpreetbedi)
- [33K](https://x.com/ashpreetbedi/status/2052413981487427871/analytics)
- [Follow these steps](https://www.docker.com/get-started/)
- [http://localhost:8000/docs](http://localhost:8000/docs)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [Railway CLI](https://docs.railway.com/cli#installing-the-cli)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [os.agno.com](https://os.agno.com/)
- [teams overview](https://docs.agno.com/teams/overview)
- [workflows overview](https://docs.agno.com/workflows/overview)
- [agents overview](https://docs.agno.com/agents/overview)
- [agno scheduler docs](https://docs.agno.com/agent-os/scheduler)
- [interfaces guide](https://docs.agno.com/agent-os/interfaces/overview)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:43 PM · May 7, 2026](https://x.com/ashpreetbedi/status/2052413981487427871)
- [33.4K Views](https://x.com/ashpreetbedi/status/2052413981487427871/analytics)
- [View quotes](https://x.com/ashpreetbedi/status/2052413981487427871/quotes)
---
*导出时间: 2026/5/8 13:31:50*
