夜雨聆风很多人理解 Agentic Programming 时，第一反应还是“让 AI 帮我写代码”。它能读 repository，能跑 shell，能改文件，能修 bug，看起来已经很像一个工程助手了。
但如果我们讨论的不是漂亮的原型，而是完整的软件工程，那么代码就不是它的全部。
Agent需要访问更多的东西。
代码只是工作的一部分
像claude code / codex 这样开箱即用的Agent，通常处在默认状态，只能看到代码仓库和 shell。
它能理解当前目录里的文件，也能执行一些命令，可真实的软件工程并不只发生在这些地方。
绝大多数工作是分散在多处。
代码当然重要，但代码往往只是结果的一部分。
需求怎么来的、谁负责推进、上一次为什么放弃某个方案、CI 为什么失败、线上指标有没有改善，这些都不是单靠读源码就能知道的。
所以，如果 Agent 只能看到 repo 和 shell，它就只能碰到“代码的表面”，却碰不到工作真正发生的地方。
Agent的工作入口
站在我们工作的视角，Agent 需要能“看到”哪些地方呢？
协作与沟通
Teams、微信、飞书、钉钉、邮件这些不是写代码的地方，但很多工程推进的关键恰恰发生在那里。
谁负责这个模块？
这个PR为什么卡住？
这个需求应该问产品、设计还是平台团队？
之前有没有人讨论过这个问题？
这些都是协作和沟通问题，不是实现问题。
很多时候，工程能不能继续往前走，取决于能不能找到正确的人、正确的线程、正确的上下文。没有这层访问能力，Agent 就只能在代码里猜，无法像人一样去路由、追问和对齐。
CI / CD
CI/CD 代表的是验证和反馈。
真实的软件工程不是写完代码就结束，而是要读失败、重跑任务、定位回归、判断问题发生在哪一步，然后根据系统发回来的信号继续调整。
这里体现的是 Agent 的一个关键能力：它不只是生成结果，还要能读懂负反馈，并基于反馈继续推进。
如果 Agent 看不到 CI/CD，它就失去了最重要的自我校正机制。
它也许能写出一段看起来正确的代码，但不知道这段代码有没有通过真实流水线的检验。
Dashboard
Dashboard 代表的是生产环境中的真实世界。
指标、错误率、告警、部署后的结果，这些信息告诉你：修复是不是已经真的落地了，系统状态是不是改善了，用户有没有继续受影响。
很多工程工作并不是改代码，而是确认改动有没有真的改变运行中的系统。
工程的终点不是 commit，而是 production。
Agent 如果看不到 dashboard，就很难判断自己是修好了问题，还是只是完成了一次代码修改。
内部文档
内部文档代表的是组织记忆和隐性知识。
设计文档、runbooks、历史决策、没人找得到但又很关键的说明文档，往往才是项目真正的知识层。
它们不在源码里，却决定了为什么这段代码要这样写，这个系统为什么要那样设计，上一次为什么没有采用某个方案。
没有这层访问能力，Agent 只能看见“结果”，看不见“为什么”，也就很容易重复团队已经踩过的坑。
你会发现，以上四点，恰恰是平时工作时除编码外，需要关注的内容。
而 Agent 作为你的助手，也需要能够连接到这四个地方。
所以为 Agent 提供可以访问这些信息的入口，是真正实现 Agentic Software Engineering 的关键。
你的工作，会从一个抽象的概念，变成几个具体入口：
沟通协调的信息 CI/CD 反馈 Dashboard 内部文档 repository shell issue PR 其他系统等
这些入口共同组成了一个复杂的网络。
一个 Agent 要真正有用，就必须能跨过这些系统，而不是只待在代码仓库里。
Claude Connector
claude的Connector的概念，表达的就是上面提到的Agent的工作入口概念。
connector真正做的事情，是把 Claude 接进你的工作现场，让它能够按你授权的范围，访问那些你工作时本来就会访问的信息源。
你不再需要先打开聊天软件，复制一段讨论，再贴给 Agent；你可以直接委派它去看某个线程、某个文档、某次 CI 失败、某个 dashboard，然后基于读到的信息继续执行任务。
所以，提供给 Agent 访问的权限，并不是“让 Claude 看见所有东西”，而是让它能在需要的时候，看见和你做决策时同一类的信息。
Agent 不需要拥有你脑子里的全部内容，但它需要能访问你做工作时会访问的那些内容。
只有这样，它才不是一个只会看 repo 的助手，而是真正和你共享工程现场的协作者。
用 TUI 来诊断缺失的Connector
尝试一整天都不离开 Claude Code TUI 来完成工作。
这不是在要求你永远待在一个界面里，而是在提供一种诊断方法。
每一次你不得不打开另一个工具、另一个页面、另一个系统，那里就是 Agent 缺失的信息或连接。
你打开聊天工具，说明它缺协作上下文；
你打开 CI，说明它缺验证反馈上下文；
你打开 dashboard，说明它缺生产状态上下文；
你打开内部文档，说明它缺组织记忆上下文。
换句话说，离开 TUI 的次数越多，就越说明 Agent 还没有接上你的真实工作流。
这个判断的价值在于，它把Connector这件事变得可观察、可枚举，可以让我们直接看到它缺了哪些连接，缺了哪些信息，缺了哪些入口。
写在最后
Agentic Software Engineering 的起点是它能不能进入真实的软件工程现场。
真正有用的 Agent，不只是会生成代码，而是能访问上下文、理解反馈、继承组织记忆，并在真实工作流里持续推进任务。
让 Agent 拥有访问你工作环境的能力，是让 Agent 从“能演示”走向“能生产”的前提。