智能体可以执行的项目计划，通过 MCP 或在应用内。
计划是唯一可信来源：任务、冲刺、里程碑、依赖关系、基线和审计日志。智能体从计划中读取，并把结构化的修改写回计划。两条路径通向同一份计划：面向任何生态中外部智能体（ChatGPT、Claude、Cursor、Codex）的 MCP 服务器，以及应用内的 Run-with-Agent。
MCP 端点 https://mcp.onplana.com/mcp
351 个 MCP 工具 · OAuth 2.1 + DCR · 幂等 · 带审计日志 · 免费，无需信用卡
智能体的每个动作都会被记录，适用于包括免费版在内的所有方案。读取和导出该日志适用于Enterprise 方案及以上。
看一个智能体完成真实的工作
一个进行中的支付迁移，以及一份还没人写的回滚手册。负责人写了两句话就把它交了出去。它在读完项目的其余部分后回来，等待有人批准。
再看一整份计划自行执行
一项委托变成一份完整的项目计划，然后 ChatGPT、Claude 和 Onplana 的 AI 各自通过这份共享计划执行自己的任务，最后的发送由一个人批准。不同的生态，一个控制平面。
选项卡里的助手问题
大多数项目工具都在应用旁边拧上一个助手。你问它问题，它在聊天面板里回答，结果留在聊天记录中。下一个打开项目的人看不到助手得出了什么结论，下一个智能体也看不到。工作的产物是一段对话，而在一段对话之上，团队和第二个智能体都无法继续构建。
解决办法是不再把计划当作聊天的上下文，而是把它当作聊天写入的基础。当智能体移动任务、标记风险或起草状态报告时，修改会落在计划本身，与人做出的修改一样经过相同的权限检查、相同的幂等性和相同的审计日志。对话是一次性的。留下来的是计划，下一个工作者，无论是人还是智能体，都从那里继续。
模式：计划即基础
两条路径写入计划。两者都经过同一道关口。
实际效果
三段真实的交互。方括号中的行是对计划的工具调用。
你：连接 Onplana，Mobile App v2
里有什么逾期了？
Claude：[list_overdue，按项目筛选]
4 项逾期。最主要的 2 项："API
rate limit handling"（Sarah，6 天），
"Push notification config"（Mike，
3 天）。两项都在 Sprint 14。
你：把它们移到 Sprint 15。把 Sarah 的
那项改派给 Mike，她已经满负荷了。
Claude：[move_task_to_sprint x2,
assign_task]
完成。两项都在 Sprint 15。
Sarah 的任务现在归 Mike。
审计日志：/audit/...[Cursor 完成刷新令牌轮换，
提交 a3f7c2]
Cursor（通过 MCP）：
update_task taskId=tsk_abc
status=DONE
create_comment "Commit a3f7c2:
刷新令牌轮换"
create_timesheet_entry hours=2
Onplana：
任务已设为 DONE。评论已发布。
2 小时记入草稿工时表。项目经理在 Q4 Launch 项目中
点击 "Run with Agent"。
目标："在站会前
找出阻碍。"
智能体读取状态：
list_tasks, list_risks, list_overdue
analyze_project_health（对评论和
状态做一遍 AI 分析）
返回一份提议：
标记 3 项风险，起草 2 项
缓解任务，4 条改派
建议。
项目经理接受 2 项风险，修改第 3 项，
接受两项缓解任务，接受
1 条改派，拒绝 3 条。状态报告
草稿已附上。两条路径，两种规模
MCP 服务器注册了 351 个工具，覆盖项目、任务、冲刺、里程碑、挣值、风险、问题、治理、变更控制、工时表、页面、白板、工作流以及 Microsoft Graph 集成。每个工具都会按调用者的角色校验、按组织的方案限制，使用客户端提供的键实现幂等，并写入审计日志。持有正确令牌的外部智能体可以触及以上全部。
无论你使用哪个方案，这条审计记录都会写入，所以从免费账户上智能体的第一次调用起，日志就已存在。回读日志、按智能体和工具筛选并导出供他人核查的界面适用于Enterprise 方案及以上。
对于在应用内自主行动的智能体来说，351 个工具的范围太大，难以驾驭，所以 Run-with-Agent 使用精选的十项能力，侧重分析、起草和提议，而不是执行不可逆的决定。它可以起草状态报告、分析项目健康状况、生成风险登记册、起草面向干系人的沟通、交接说明或任何文档，把任务拆分为子任务，从笔记中提取行动项，记录一项决定，并用一组安全的工具完成一项委托。Run-with-Agent 的每项能力在设计上都只做新增：它写入新的产物，从不修改已有的行，如果某项能力声明了相反的行为，测试会让构建失败。它不能在冲刺之间移动任务、改派人员、批准工时表或推进治理关口。这些仍由人掌握，由人接受、修改或拒绝每一项提议。文档涵盖这个循环的两半：把工作分配给智能体（英文）和审阅它产出的内容（英文）。
删除是受治理的，而不是不存在的，并且在关键之处可以恢复。通过 MCP 公开了四个破坏性工具：删除任务、项目、列表或文档。每一个都是按工作区设置的开关，在管理员保存选择之前处于开启状态，而调用者仍然需要原本就需要的权限。这四个工具全部可以恢复：被删除的任务或项目连同整个子树进入回收站，恢复时会用原始标识符重建它，所以依赖关系、层级和链接都能完整往返。冲刺、里程碑、史诗和目标在 MCP 中没有任何删除工具。应用内的 Run-with-Agent 被禁止执行任何删除。让这对自主智能体来说安全的，正是人们所依赖的同一件事：没有任何结构性的东西会永久消失。
在哪里运行，以及如何避免冲突
智能体从你已经在工作的地方连接：装有 Claude Code 或 Codex 的终端、Cursor，或者 ChatGPT 和 Claude 本身，它们在各自的连接器目录中收录了 Onplana。这条路径不花任何费用，适用于包括免费版在内的所有方案。加上已发布的中继包，一旦有人评论、提及智能体角色或按下 Run with Agent，本地运行器就会立即启动，而不必等待下一次轮询，无需公开的监听器，也无需入站防火墙规则。
托管执行是第三种选择，适合没人愿意让笔记本一直开着的情况。Onplana 维持连接并启动智能体，实际工作委托给 Claude 托管的智能体沙盒，使用你提供并可撤销的凭据。你从不接触 Onplana 令牌：托管服务生成、持有并保管自己的令牌，而且生成的权限与 Connect Agent 窗口授予的完全一致，所以托管绝不是通往更大权限的隐蔽途径。凭据在读取时与其连接绑定，并在使用时重新核对，因此一个客户的密钥无法用于另一个客户的启动。它按智能体日计量，即托管连接的一天，不论启动多少次，Professional 方案及以上包含一定配额，任何方案都可以购买额外天数。
一旦同一个待办列表上有不止一个智能体，值得关注的故障就是两个智能体开始同一项任务。Onplana 提供一个排他租约：一次调用选出下一个可用任务并认领它，因为先列出再认领会留下一个两者都可能落入的空隙。租约属于这次执行而不属于用户，这比看上去更重要，因为同一工作区中的两个 Claude Code 会话会以同一个智能体角色进行身份验证，按用户的租约会让一个会话释放另一个会话的工作。租约会自行过期，所以崩溃的智能体会释放它的任务，而不是让任务停滞，完成任务或将其标记为受阻也会立即归还租约。
面向工程团队的页面从头到尾走完了整个循环：面向软件团队的 Onplana。
技术与合规
- 前端
- React、TypeScript、Vite
- 后端
- Node、Express、Prisma。Postgres，自定义字段采用 EAV 模型，在受影响的子图上重新计算 CPM，Redis。
- 基础设施
- Azure Container Apps、Azure DNS
- MCP
- 符合规范的服务器。OAuth 2.1 + Dynamic Client Registration、PKCE S256、401 + WWW-Authenticate 响应，以及 initialize 握手中的 agent_bootstrap。
- 身份
- SAML 2.0、OIDC、SCIM 2.0，经 Microsoft Entra 端到端验证。
- 导入
- 通过 MPXJ 导入 Microsoft Project 的 .mpp 文件。
我们还没有的东西
Free 方案包含的 AI 是一次性的令牌奖励，并非无限，所以大量的自动化使用需要付费方案或预付额度。这是一个真实的取舍，我们明说而不是隐藏。