AgentRun CLI：面向AI Agent的声明式操作系统
1. 项目概述：这不是又一个 CLI 工具，而是一把“AI Agent 操作系统”的启动钥匙
“AgentRun CLI v0.1.0 正式开源：一行命令运行您的托管 Agent”——这个标题里藏着三个被多数人忽略的关键词： 托管（hosted） 、 一行命令（one-command） 、 CLI 。它不是让你本地跑个 Python 脚本，也不是教你写 prompt 工程，而是把整个 AI Agent 的生命周期——从创建、配置、运行、调试到销毁——压缩进一个终端命令里。我第一次在钉钉群里看到同事输入 ar super-agent run --prompt "你是个前端架构师" ，三秒后就弹出一个带上下文记忆的 REPL 界面，他直接问：“怎么用 React 实现一个可拖拽的甘特图组件？”，然后 agent 就开始写代码、解释原理、甚至主动问要不要生成 demo 页面。那一刻我就意识到，这玩意儿不是玩具，是生产力拐点。
它解决的核心问题非常具体： AI Agent 开发者长期被困在“胶水层”里 。你要调模型 API、要管工具调用链、要处理 sandbox 权限、要写 YAML 配置、要部署 runtime、还要做状态持久化……这些事加起来，80% 的时间花在基础设施上，而不是在设计 agent 行为本身。AgentRun CLI 的思路很硬核：把所有平台能力封装成声明式资源（SuperAgent、Runtime、Sandbox、Tool），再用统一的 CLI 命令驱动。它不碰 LLM 底层，但把 LLM 上层的工程复杂度砍掉 90%。适合谁？不是给纯算法研究员看的，而是给那些已经能写 prompt、会调 OpenAI API、但一想到要搭 agent infra 就头皮发麻的工程师、MLOps 工程师、甚至懂技术的产品经理。它不替代你的思考，但让你的思考能立刻落地执行。YAML 不是负担，而是 agent 的“源代码”；CLI 不是外壳，而是你和 agent 平台之间的神经接口。
2. 核心设计逻辑：为什么是 CLI + YAML + 托管模式？而不是 Web 控制台或 SDK？
2.1 CLI 作为唯一入口：不是为了炫技，而是为了可编程性与确定性
很多人第一反应是：“有 Web 控制台了，为啥还要 CLI？” 这是个好问题。我试过用控制台创建 5 个不同配置的 agent，每一步都要点鼠标、填表单、等刷新，改个 tool 配置得重新走一遍流程。而 CLI 的价值，在于它天然支持 幂等性、可复现性、可集成性 。 ar super-agent apply -f superagent.yaml 这条命令，无论你执行 1 次还是 100 次，只要 YAML 文件没变，最终状态就完全一致。这背后是 Kubernetes 风格的声明式 API 设计哲学：你告诉平台“我要什么状态”，而不是“请执行哪几步操作”。
更关键的是 确定性退出码 。CLI 文档里明确写了：成功是 0，参数错误是 1，认证失败是 2，权限不足是 3。这意味着你可以把它无缝嵌入 CI/CD 流水线。比如在 GitHub Actions 里，你完全可以写：
- name: Deploy staging agent
run: ar super-agent apply -f agents/staging.yaml --profile staging
if: github.ref == 'refs/heads/main'
如果命令返回非 0，流水线自动失败，根本不用写一堆 shell 判断逻辑。而 Web 控制台做不到这点——它没有退出码，没有 JSON 输出，没有管道（pipe）能力。你无法用 | jq '.status' 去解析它的响应。CLI 的 JSON-by-default 输出，让自动化成为呼吸般自然的事。我实测过，用 ar sa invoke my-helper -m "Summarize this PR" --text-only | jq -r '.response' 直接把 agent 输出喂给 Slack bot，整个链路零胶水代码。
2.2 YAML 作为声明式契约：不是配置文件，而是 agent 的“数字身份证”
网络热词里反复出现 “yaml 语法”、“yaml 文件内容格式”，说明很多人对 YAML 的理解还停留在“比 JSON 好写点的配置”。但在 AgentRun 里，YAML 是 agent 的完整契约（contract） 。看这个 superagent.yaml 片段：
apiVersion: agentrun/v1
kind: SuperAgent
metadata:
name: code-reviewer
description: "PR 自动审查助手，集成 GitHub API 和 CodeQL"
spec:
prompt: |
你是一个资深的代码审查员。请严格检查 PR 中的：
- 安全漏洞（SQL 注入、XSS、硬编码密钥）
- 代码风格（PEP8、ESLint 规则）
- 逻辑缺陷（空指针、资源泄漏）
- 测试覆盖率是否达标
tools:
- github-pr-api
- codeql-scan
sandboxes:
- name: pr-check-sandbox
spec:
filesystem: readonly
network: github.com, api.github.com
timeout: 300s
这里 spec.tools 不是简单列个名字，而是告诉平台：“请为这个 agent 预装并授权这两个 MCP（Model Context Protocol）工具”； sandboxes 里的 network 字段，是平台在底层为你创建了一个网络策略隔离的容器环境，只允许访问指定域名。YAML 的每一行，都在定义 agent 的 行为边界、能力范围、安全策略 。它不是“怎么部署”，而是“它应该是什么”。这种声明式思维，让 agent 变得像 Kubernetes Pod 一样可版本化、可审计、可 diff。你用 git diff 就能看出上周和这周 agent 的能力变化，这是任何图形界面都做不到的透明度。
2.3 托管模式（Hosted）：卸下运维重担，专注智能逻辑设计
“托管”这个词在标题里很轻，但分量最重。它意味着你不需要关心：GPU 资源调度、模型服务扩缩容、sandbox 进程隔离、工具调用超时熔断、对话历史持久化、token 用量监控……这些全由 AgentRun 平台兜底。我对比过自建方案：用 FastAPI 写个 agent server，光是实现 sandbox 的进程级资源限制（CPU 100m, Memory 512Mi）和网络白名单，就得啃一周 cgroups 和 iptables 文档。而 AgentRun CLI 里， sandbox 的 timeout: 300s 一行就搞定，平台在底层用 eBPF 做精准超时控制。
托管带来的另一个隐性价值是 跨环境一致性 。你在本地 ar super-agent run 调试时用的 sandbox 环境，和线上 ar super-agent apply 部署的，是同一套 runtime。不存在“本地跑得好，线上挂得快”的经典陷阱。因为所有依赖（Python 版本、系统库、工具二进制）都打包在平台预置的 sandbox 镜像里。你写的 YAML，就是 agent 的全部事实（single source of truth）。这彻底改变了开发范式：以前是“写代码 → 部署 → 调试 → 改代码”，现在是“写 YAML → 本地 run → 线上 apply → 完事”。我把这个过程称为“YAML Driven Development”（YDD），它让 AI agent 开发回归到软件工程的本质：用声明式语言描述需求，让平台负责实现。
3. 核心功能拆解与实操细节：从零开始跑通一个真实 agent
3.1 快速上手：三步完成首个托管 agent（含避坑指南）
很多新手卡在第一步——安装后 ar --version 报错。这不是你的问题，是环境变量没生效。官方文档说“下载二进制”，但没强调 Windows 用户必须把 agentrun.exe 所在目录加进 PATH ，否则 PowerShell 里永远提示 ar : The term 'ar' is not recognized 。Mac/Linux 用户也常忽略 chmod +x 权限。我的实操步骤是：
-
安装（推荐 PyPI 方式，最稳） ：
# 确保 pip 是最新版 pip install --upgrade pip # 安装 CLI（注意包名是 agentrun-cli，不是 agentrun） pip install agentrun-cli # 验证 ar --version # 应输出 v0.1.0提示：如果 pip 安装报
yaml相关错误（如undefined reference to 'yaml'），说明系统缺 libyaml-dev。Ubuntu/Debian 执行sudo apt-get install libyaml-dev，CentOS/RHEL 执行sudo yum install libyaml-devel，Mac 执行brew install libyaml。这是网络热词里高频出现的报错，根源是 PyYAML 的 C 扩展编译失败。 -
配置凭证（最关键的一步，90% 的失败源于此） ：
# 这四行必须按顺序执行，且 account_id 是纯数字（不是字符串！） ar config set access_key_id LTAI5tQxxxxxxxxxxxxxx ar config set access_key_secret xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ar config set account_id 1234567890123456789 # 注意：这里不能加引号，必须是数字 ar config set region cn-hangzhou注意：
account_id必须是阿里云主账号的 16 位数字 ID，不是 RAM 子用户的 ID。如果你用子用户，必须确保该子用户已绑定AliyunAgentRunFullAccess策略。我第一次就填错了，ar super-agent run一直报exit code 3，查日志才发现是权限问题。凭证文件默认存在~/.agentrun/config.json，你可以用cat ~/.agentrun/config.json直接查看，确认account_id字段是数字类型。 -
运行首个 agent（体验“一行命令”的魔力） ：
# 直接运行，无需 YAML ar super-agent run --prompt "你是一个 Linux 系统管理员" # 等待几秒，看到 "Ready. Type your message (/help for commands)." 即可开始对话 > 查看当前磁盘使用率 > 显示最近 5 个失败的 systemd 服务 > /exit # 退出 REPL这条命令背后发生了什么？CLI 先向 AgentRun 平台发起请求，平台动态创建一个 sandbox（基于 Ubuntu 22.04 镜像），注入
systemctl,df,journalctl等命令，并设置好/var/log的只读挂载。整个过程对用户完全透明。你退出后，agent 实例依然存活，下次用ar sa chat <name>就能续上对话。这个<name>是 CLI 自动生成的，如super-agent-tmp-20260420213045，你可以在ar sa list输出里看到。
3.2 声明式部署：用 YAML 管理 agent 的“生老病死”
手动 run 适合调试，但生产环境必须用 YAML。我们来构建一个真实的“数据分析师 agent”，它能连接数据库、执行 SQL、生成图表：
# analyst-agent.yaml
apiVersion: agentrun/v1
kind: SuperAgent
metadata:
name: data-analyst-prod
labels:
env: production
team: analytics
spec:
prompt: |
你是一个专业的数据分析师。用户会提供 SQL 查询或分析需求。
你必须：
1. 先确认数据库连接是否正常（用 `SELECT 1`）
2. 执行用户 SQL，返回结果（最多 100 行）
3. 如果结果含数值列，用 matplotlib 生成柱状图/折线图
4. 解释分析结论，给出业务建议
tools:
- postgresql-client
- matplotlib-plot
sandboxes:
- name: db-sandbox
spec:
filesystem: readwrite
network:
- postgresql.mycompany.internal:5432
- s3.mycompany.internal
timeout: 600s
resources:
cpu: 1000m
memory: 2Gi
workspaces:
- name: analysis-workspace
spec:
type: s3
bucket: "mycompany-analytics-results"
prefix: "reports/"
部署只需一条命令：
ar super-agent apply -f analyst-agent.yaml
# 输出：action: "created"
这条 YAML 定义了 agent 的全部生命体征：
tools指定了两个预装工具：postgresql-client（用于连接内网 PostgreSQL）和matplotlib-plot（用于绘图）；sandboxes创建了一个名为db-sandbox的隔离环境，网络只允许访问内网 PostgreSQL 和 S3，CPU 和内存有硬限制；workspaces绑定了一个 S3 存储桶，agent 生成的图表会自动存到s3://mycompany-analytics-results/reports/下。
实操心得：YAML 里的
network字段必须写 完整域名+端口 ，不能只写postgresql.mycompany.internal。我第一次漏了:5432，sandbox 启动后连不上数据库，查日志发现是 DNS 解析成功但连接超时。另外，resources里的cpu: 1000m是 Kubernetes 标准写法，代表 1 个 vCPU，memory: 2Gi是 2GB 内存。这些值不是随便写的，平台会据此分配物理资源，设太小 agent 会 OOM，设太大浪费钱。
3.3 多资源协同：一个 YAML 文件管理 agent 生态系统
Agent 很少单打独斗。一个典型场景是： data-analyst agent 需要调用 report-generator agent 来生成 PDF 报告。AgentRun 支持多文档 YAML（用 --- 分隔），在一个文件里定义多个资源：
# full-stack-agent.yaml
# 第一个文档：定义 Runtime（agent 的运行时环境）
apiVersion: agentrun/v1
kind: AgentRuntime
metadata:
name: report-runtime
spec:
container:
image: registry.cn-hangzhou.aliyuncs.com/my-ns/report-generator:v2.1
cloudBuild:
dir: ./report-gen
setupScript: build.sh
---
# 第二个文档：定义 SuperAgent
apiVersion: agentrun/v1
kind: SuperAgent
metadata:
name: data-analyst-prod
spec:
prompt: "..."
tools:
- postgresql-client
- report-generator-tool # 这个 tool 会调用上面定义的 runtime
sandboxes: [...]
部署时，CLI 会自动识别 --- 分隔符，先创建 AgentRuntime （如果镜像不存在，会触发 cloudBuild ），再创建 SuperAgent 。 report-generator-tool 这个工具的实现，就是通过 MCP 协议，向 report-runtime 的 endpoint 发送 HTTP 请求。整个生态的依赖关系，全在 YAML 里声明清楚。
注意事项：多文档 YAML 的执行顺序很重要。
AgentRuntime必须在SuperAgent之前定义，否则SuperAgent创建时找不到 runtime。CLI 不会自动排序，它按 YAML 文件里的顺序执行。所以务必把基础资源（Runtime、ModelService）放在前面，上层应用（SuperAgent）放在后面。我曾把顺序搞反，ar super-agent apply报错runtime 'report-runtime' not found，花了半小时才意识到是 YAML 顺序问题。
4. 深度实操：从调试到生产化的全链路实践
4.1 调试技巧：如何像调试程序一样调试 agent 行为？
CLI 提供了强大的调试能力，远超 Web 控制台。核心是 --debug 和 --verbose 标志：
# 查看 CLI 与平台的完整 HTTP 交互（含请求头、响应体）
ar super-agent run --prompt "test" --debug
# 查看 sandbox 内部执行的每一条命令（相当于 strace）
ar sa chat data-analyst-prod --verbose
--debug 输出会显示：
- CLI 向
https://agentrun.api.aliyuncs.com/v1/super-agents发起的 POST 请求； - 请求体中的
spec.prompt、spec.tools等字段； - 平台返回的
agentId、sandboxId、websocketUrl。
--verbose 则会实时打印 sandbox 里执行的命令：
[INFO] Executing command: psql -h postgresql.mycompany.internal -U analyst -d sales -c "SELECT COUNT(*) FROM orders;"
[INFO] Command output: " count \n-------\n 12456\n(1 row)\n"
这让你能精准定位问题：是 prompt 写错了？是 tool 没授权？还是 sandbox 网络不通？我遇到过一次 agent 总是返回空结果，开 --verbose 后发现 psql 命令因密码错误被拒绝，立刻去检查 postgresql-client tool 的 credential 配置。
另一个神器是 ar sandbox exec 。它让你像 kubectl exec 一样，直接进入 agent 的 sandbox 环境：
# 列出所有 sandbox
ar sandbox list
# 进入指定 sandbox 的 bash
ar sandbox exec db-sandbox -- bash
# 在里面手动测试数据库连接
psql -h postgresql.mycompany.internal -U analyst -d sales -c "SELECT 1;"
这比在 REPL 里反复试错高效十倍。sandbox 是一个标准的 Linux 容器，你可以用 top , df , netstat 等一切命令排查。
4.2 生产化部署：CI/CD 集成与灰度发布
把 agent 推到生产，不能靠手工 apply 。我们用 GitHub Actions 实现自动化：
# .github/workflows/deploy-agent.yml
name: Deploy Agent
on:
push:
branches: [main]
paths: ['agents/**.yaml']
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# 安装 AgentRun CLI
- name: Install AgentRun CLI
run: pip install agentrun-cli
# 配置凭证（从 GitHub Secrets 读取）
- name: Configure AgentRun
run: |
ar config set access_key_id ${{ secrets.AGENTRUN_ACCESS_KEY_ID }}
ar config set access_key_secret ${{ secrets.AGENTRUN_ACCESS_KEY_SECRET }}
ar config set account_id ${{ secrets.AGENTRUN_ACCOUNT_ID }}
ar config set region ${{ secrets.AGENTRUN_REGION }}
# 部署所有 YAML 文件
- name: Apply Agents
run: |
for file in agents/*.yaml; do
echo "Applying $file"
ar super-agent apply -f "$file" --profile prod || exit 1
done
灰度发布怎么做？AgentRun 支持 --profile ，你可以为不同环境创建独立 profile：
# 创建 staging profile
ar config set --profile staging access_key_id ...
ar config set --profile staging access_key_secret ...
# 部署到 staging
ar super-agent apply -f analyst-agent.yaml --profile staging
# 验证无误后，再部署到 prod
ar super-agent apply -f analyst-agent.yaml --profile prod
实操心得：在 CI/CD 里， 永远不要在同一个 profile 下混用 staging 和 prod 。我见过团队把 staging 的
access_key_id错粘贴到 prod profile，导致所有 prod agent 被删除。最佳实践是：每个环境用独立的阿里云 RAM 用户，且 RAM 用户只拥有对应环境的资源权限（通过 Resource Group 实现）。这样即使凭证泄露，影响也局限在单个环境。
4.3 高级功能：Runtime 自定义与云构建（Cloud Build）
当预置的 sandbox 不够用，你需要自定义 runtime。比如，你的 agent 需要调用一个私有 Python 包 my-ml-lib ，而这个包不在官方 sandbox 镜像里。这时就要用 AgentRuntime ：
# custom-runtime.yaml
apiVersion: agentrun/v1
kind: AgentRuntime
metadata:
name: ml-agent-runtime
spec:
container:
image: registry.cn-hangzhou.aliyuncs.com/my-ns/ml-agent:v1.0
cloudBuild:
dir: ./ml-agent
setupScript: build.sh
baseContainerConfig:
image: serverless-registry.cn-hangzhou.cr.aliyuncs.com/functionai/python39-sandbox:20260514
cloudBuild 字段告诉平台：请用 build.sh 脚本，在 python39-sandbox 基础镜像上构建你的自定义镜像。 build.sh 内容可能是：
#!/bin/bash
pip install -r requirements.txt
pip install git+https://github.com/myorg/my-ml-lib.git
构建完成后，镜像会推送到 registry.cn-hangzhou.aliyuncs.com/my-ns/ml-agent:v1.0 。之后，你就可以在 SuperAgent 的 YAML 里引用它：
spec:
tools:
- my-ml-tool
runtime: ml-agent-runtime # 关联上面定义的 runtime
注意：
baseContainerConfig.image必须是 AgentRun 官方支持的 sandbox 基础镜像（如python39-sandbox），不能随便写ubuntu:22.04。因为官方镜像里预装了 sandbox agent、MCP 通信组件、资源监控探针等必需模块。用非官方镜像会导致 runtime 启动失败。
5. 常见问题与独家排查指南：那些文档里不会写的坑
5.1 高频报错速查表
| 报错信息 | 根本原因 | 解决方案 | 我的踩坑经历 |
|---|---|---|---|
exit code 3 或 AccessDenied |
RAM 用户缺少 AliyunAgentRunFullAccess 策略，或 account_id 填错 |
1. 登录 RAM 控制台，为该用户附加策略 2. 检查 ~/.agentrun/config.json 中 account_id 是否为 16 位纯数字 |
我第一次用子用户，没绑策略，查了 2 小时日志，最后发现 ar config set account_id "1234567890" 里加了引号，JSON 解析成字符串，平台认为是非法 account_id |
ar: command not found (Windows) |
agentrun.exe 未加入系统 PATH |
1. 找到 agentrun.exe 所在目录（如 C:\Users\me\Downloads ） 2. 右键“此电脑”→“属性”→“高级系统设置”→“环境变量”→“系统变量”→“PATH”→“编辑”→“新建”→粘贴目录路径 |
Windows 用户最容易忽略这一步，PowerShell 默认不搜索当前目录 |
undefined reference to 'yaml' |
系统缺少 libyaml 开发库 | Ubuntu/Debian: sudo apt-get install libyaml-dev CentOS/RHEL: sudo yum install libyaml-devel Mac: brew install libyaml |
这是网络热词里最常搜的报错，根源是 PyYAML 的 C 扩展编译失败，必须先装系统库 |
Failed to connect to websocket |
防火墙或代理阻止了 WebSocket 连接（端口 443） | 1. 检查公司防火墙是否放行 *.agentrun.aliyuncs.com 2. 如果用代理，CLI 不支持 proxy，需配置系统级代理或联系 IT 开通直连 |
我们公司网络策略严格， ar super-agent run 卡在 Connecting... ，抓包发现 WebSocket 握手被 reset，最后 IT 开通了域名白名单 |
tool 'xxx' not found |
YAML 中写的 tool 名字与平台注册的不一致 | 1. 运行 ar tool list 查看所有可用 tool 2. 确认名字完全匹配（区分大小写） |
我把 postgresql-client 误写成 postgres-client ，CLI 不报错，但 agent 运行时报 tool 初始化失败 |
5.2 独家避坑技巧：提升 300% 的开发效率
-
YAML 编辑器必装插件 ：VS Code 安装
Red Hat YAML插件，并配置 schema。AgentRun 提供了官方 YAML Schema（在docs/en/schema/目录），把它关联到*.yaml文件，就能获得智能提示、语法校验、字段描述。写spec.tools时，输入-就会自动列出所有可用 tool，再也不用翻文档。 -
本地沙盒模拟（Local Sandbox Mock） ：CLI 本身不提供本地 sandbox，但你可以用 Docker 模拟：
# 拉取官方 sandbox 镜像 docker pull serverless-registry.cn-hangzhou.cr.aliyuncs.com/functionai/python39-sandbox:20260514 # 启动并挂载你的代码 docker run -it --rm -v $(pwd):/workspace -w /workspace serverless-registry.cn-hangzhou.cr.aliyuncs.com/functionai/python39-sandbox:20260514 bash在这个容器里，你可以提前测试
psql、curl等命令是否能连通你的内网服务，避免部署后才发现网络不通。 -
对话历史导出与回放 ：
ar sa chat时，CLI 会把每次对话存到本地~/.agentrun/conversations/。你可以用cat ~/.agentrun/conversations/conv-9f8e7d6c-xxx.json查看原始 JSON，里面有完整的user_message、agent_response、tool_calls、tool_results。这对 debug tool 调用链极其有用。我还写了个小脚本，把 conversation JSON 转成 Markdown，方便分享给同事复现问题。 -
性能监控黄金指标 ：在生产环境，关注这三个 CLI 命令：
# 查看 agent 的平均响应时间（毫秒） ar super-agent get data-analyst-prod --output json | jq '.status.latencyMs' # 查看 sandbox 的 CPU 和内存使用率 ar sandbox get db-sandbox --output json | jq '.status.resources' # 查看 tool 调用成功率 ar tool get postgresql-client --output json | jq '.status.successRate'把这些命令写进 cron job，定期采集，就能构建自己的 agent SLO 看板。
6. 生态扩展与未来演进：从 CLI 到 agent 开发平台
AgentRun CLI v0.1.0 是一个极简但完备的起点。它的设计预留了强大的扩展性。比如， model 命令组允许你注册外部 LLM 服务：
# 注册一个私有部署的 DeepSeek 模型
ar model register --name deepseek-v2 --endpoint https://deepseek.mycompany.ai/v1 --api-key $KEY
# 然后在 SuperAgent YAML 里引用
spec:
model: deepseek-v2
这让你能混合使用公有云模型（如 Qwen）和私有模型，满足数据合规要求。
另一个重要方向是 MCP（Model Context Protocol）工具生态 。目前 CLI 内置了 mcp-time-sa 、 postgresql-client 等工具，但社区可以贡献自己的工具。工具本质是一个符合 MCP 规范的 HTTP 服务，CLI 会自动发现、认证、调用。我正在开发一个 jira-ticket-tool ，让 agent 能直接创建 Jira issue。它的 YAML 定义只有几行：
apiVersion: agentrun/v1
kind: Tool
metadata:
name: jira-ticket-tool
spec:
endpoint: https://jira-tool.mycompany.ai
auth:
type: bearer
token: $JIRA_API_TOKEN
注册后，任何 agent 都能通过 tools: [jira-ticket-tool] 获得这个能力。这就是 CLI 构建的“工具市场”雏形。
我个人在实际操作中的体会是：AgentRun CLI 的价值，不在于它今天能做什么，而在于它定义了一种新的 AI agent 开发范式—— 以 CLI 为入口、以 YAML 为契约、以托管为基石 。它把 AI agent 从“黑盒实验品”变成了“可版本化、可测试、可部署的软件资产”。当你能把一个 agent 的全部能力，用 20 行 YAML 清晰定义，并用一条命令在任意环境复现时，你就真正掌握了 AI 时代的工程化能力。下一步，我计划用它把我们团队的 12 个内部工具（代码扫描、日志分析、监控告警）全部封装成 MCP 工具，让新来的实习生也能用自然语言调用整个研发栈。这不再是科幻，而是明天早上就能上线的现实。
更多推荐
7
0- 0
已为社区贡献3条内容
所有评论(0)